This post covers what replaces what, what you gain in the migration, and the one gap we’re honest about. For a complete profiler-by-profiler mapping, see the AQTime migration guide.

What AQTime covered

AQTime was a single product that bundled 15 profilers: memory leak detection, resource tracking, COM reference counting, code coverage (two variants), performance profiling (instrumented and sampling), plus several secondary tools for exception tracing, fault injection, function tracing, and static analysis.

The appeal was obvious — one licence, one UI, one installation. The three capabilities that most developers actually used were: memory analysis, code coverage, and performance profiling. Those three map directly to three Software Verify products.

The thing worth knowing before you migrate

AQTime’s native-code profiling support stopped at Visual Studio 2010.

That’s not a typo. AQTime’s profilers for unmanaged C++ code support MSVC version 4 through 10 — that’s Visual Studio up to and including VS 2010. Any developer writing C++11, C++14, C++17, C++20, or C++23 in Visual Studio 2012 or later cannot fully use AQTime’s native profilers. The documentation hasn’t been updated since January 2022, and the compiler support hadn’t been updated for years before that.

If you’ve been struggling to get meaningful results from AQTime on a modern build, this is likely why.

Our tools support MSVC from Visual C++ 6 through Visual Studio 2026. Every version in between. The same applies to GCC, Clang, Delphi, and Rust — if we can read debug information from the compiler, we can instrument the application.

Memory analysis → Memory Validator

AQTime split memory tracking across three separate profilers:

• The Allocation Profiler tracked heap memory — but allocation tracking was disabled by default. You had to specifically enable “Check system memory allocations” before any allocation data appeared. Their own documentation acknowledged this generated lots of results and could cause out-of-memory issues within AQTime itself.
• The Resource Profiler tracked Windows handles, GDI objects, fonts, brushes, bitmaps, registry handles, COM objects, and print spooler entries.
• The Reference Count Profiler tracked COM AddRef/Release on interface objects.

Memory Validator covers all three in one tool, with everything enabled by default. You don’t prepare a project, don’t configure which resource types to track, and don’t worry about which profiler covers which category. Load your application, run it, see what leaked.

On top of what AQTime covered, Memory Validator also tracks GDI handles, Windows kernel handles, and .NET handles — all of which AQTime’s Resource Profiler did not track separately. If GDI exhaustion or Windows handle exhaustion has been a problem you’ve been debugging manually, Memory Validator surfaces these automatically.

Code coverage → Coverage Validator

AQTime offered two coverage tools: Coverage Profiler for thorough line-by-line tracking with hit counts, and Light Coverage Profiler for faster runs without hit counts — useful for daily regression testing.

Coverage Validator handles both use cases through a single instrumentation setting. The default mode gives full line coverage with visit counts at practical speed. If you need maximum throughput for a regression pipeline, switching to the lighter instrumentation mode takes seconds. AQTime required two separate products; we handle it with one dial.

Coverage Validator supports every compiler version AQTime’s coverage profiler supported, and every compiler version AQTime’s profiler never got to: VS 2012 through 2026, modern GCC, Clang, Delphi, Rust.

Performance profiling → Performance Validator

AQTime’s Performance Profiler was an instrumented profiler with 13 measurement counters — elapsed time, CPU cache misses, context switches, page faults, and several others. It also had a documented BSOD risk when certain counters were used with the Windows DDK installed, and timing accuracy caveats for SpeedStep processors and virtual machines.

Performance Validator is an instrumented profiler with a sampling option. The instrumented mode gives exact call counts, complete call graphs, and line-level timing. It works with any application where debug information is available — which means VS 6 through 2026, Delphi, GCC, Clang, and anything else that produces a PDB, TDS or DWARF output. No BSOD risk, no hotfix requirements.

AQTime also had a Sampling Profiler — statistical profiling that polls at intervals rather than instrumenting every call. It was unmanaged code only, and their documentation recommended quad-core hardware for accuracy. Performance Validator covers both approaches: use instrumented mode for exact call counts and full call graphs, or switch to sampling mode when you want lower overhead.

The gap we’ll be honest about

AQTime’s Failure Emulator injected controlled failures into Windows API calls — COM failures, file access failures, memory allocation failures, registry failures — to test how an application handles error paths. This is genuinely useful work: most applications handle the happy path well and fall apart when malloc returns NULL or a registry key goes missing.

We don’t have a direct equivalent right now. Fault Validator is something we plan to build — AQTime’s Failure Emulator showed the demand was real, and their exit leaves a gap in the market. If fault injection was a core part of your workflow, we don’t have a replacement today and we’re not going to pretend otherwise.

AQTime’s Function Trace

AQTime’s Function Trace profiler logged every function call with actual parameter values — a powerful debugging aid for tracing exact execution paths. Our equivalent is Bug Validator, which records parameter values, local variable values, and register values at every function entry, exit, and line visit. It covers more than AQTime’s Function Trace did. The honest caveat: Bug Validator is currently in beta and 32-bit only. If you were using Function Trace on 64-bit code, 64-bit Bug Validator support is in development.

Starting the migration

If the single-licence appeal of AQTime was important to you, we have suites that cover the same ground.

The Support Suite includes Memory Validator and Performance Validator.

The QA Suite includes Memory Validator, Coverage Validator, and Performance Validator — the three tools that replace AQTime’s core capabilities.

The Developer Suite includes Memory Validator, Coverage Validator, Performance Validator, and Thread Validator for thread analysis and deadlock detection.

All tools are available as fully functional 30-day trials. No feature restrictions during the trial.

If you have questions about specific AQTime workflows and how they map to our tools, contact us directly. We’re happy to walk through your setup.

AQTime 8 documentation is available at support.smartbear.com/aqtime/docs/ until the end of June 2026, if you need to reference it during migration.

The post AQTime Is Shutting Down. Here’s What Replaces It. appeared first on Software Verify.

This post covers what Memory Validator replaces, where it goes further, and the one area where you will need a separate tool. For a full capability mapping, see the Insure++ migration guide.

What Insure++ did

Insure++ was a C and C++ memory debugger for Windows. Its headline capability was patented source code instrumentation — to get full analysis, you compiled and linked your application through Insure++, which generated its own instrumented build and passed it to your actual compiler. The result was deep visibility into memory errors: heap corruption, buffer overflows, use-after-free, double-free, uninitialized memory reads, array out of bounds. Insure++ also included built-in code coverage and a graphical memory visualisation view.

It was a well-regarded tool with 25 years in the market. Boeing, Lockheed Martin, L3Harris, and Thales were among its customers. If it was part of your workflow, finding a replacement that actually covers what you need is worth doing carefully.

Compiler and OS support

Insure++ supported Visual Studio 2015, 2017, and 2019. Visual Studio 2022 and 2026 were not supported. On the OS side, Insure++ supported Windows 10, Windows Server 2008, Windows Server 2012, and Windows Server 2019. Windows 11 and Windows Server 2022 were not supported.

Memory Validator supports Visual C++ 6 through Visual Studio 2026, and runs on all versions of Windows from XP through Windows 10 and 11, and all equivalent server versions.

The recompile requirement

The most significant workflow difference between Insure++ and Memory Validator is instrumentation approach. Insure++ required you to recompile and relink your application every time you wanted a full analysis run. Memory Validator instruments at the binary level, at runtime. You do not recompile. You do not relink. You attach to your existing build and run.

For daily debugging work, this compounds quickly. Every iteration that would have triggered a recompile-and-relink cycle with Insure++ is an immediate run with Memory Validator.

Memory errors: what Memory Validator covers

Memory Validator detects heap memory leaks, heap corruption, and buffer overwrites. It also detects double-free and use-after-free — in Memory Validator this is called deleted-this detection. Deleted-this is off by default because it adds an instrumentation step, but enabling it requires no recompile. It is a settings change.

Memory Validator can see leaks in all DLLs your application loads — including third-party libraries you do not own source for. The only leaks it does not report are those originating inside Microsoft’s own DLL internals, where the allocation is paired with a deallocation you cannot intercept, and any DLLs you have explicitly told Memory Validator to ignore. Everything else is visible.

Beyond what Insure++ tracked

Insure++ tracked heap memory. Memory Validator tracks heap memory, GDI handles, Windows kernel handles, and .NET handles.

GDI handle exhaustion and Windows handle exhaustion are genuine problems in Windows applications — they surface as crashes or degraded behaviour after extended runtime, and they are difficult to diagnose without a tool that specifically tracks them. Insure++ did not track these. If you have been relying on Insure++ for memory analysis and hitting handle-related problems separately, Memory Validator covers both in the same session.

The displays

Insure++ had memory visualisation. Memory Validator’s graphical displays are more detailed: more dedicated views showing the collected data from different angles, colour coding that conveys information at a glance, and richer callstack data per allocation. If you found Insure++’s visualisation useful, Memory Validator’s is better.

Code coverage

Insure++ bundled code coverage alongside memory analysis in a single product. Memory Validator does not include code coverage — that is a separate product, Coverage Validator. If code coverage was part of your Insure++ workflow, you will need both Memory Validator and Coverage Validator to replace it.

Coverage Validator is available individually or as part of the QA Suite, which bundles Memory Validator, Coverage Validator, and Performance Validator in a single purchase.

Suites

If you want a single-licence option:

The Support Suite includes Memory Validator and Performance Validator.

The QA Suite includes Memory Validator, Coverage Validator, and Performance Validator.

The Developer Suite includes Memory Validator, Coverage Validator, Performance Validator, and Thread Validator.

Starting the migration

Memory Validator and Coverage Validator are both available as fully functional 30-day trials. No feature restrictions during the trial.

If you have questions about how your specific Insure++ workflow maps to our tools, contact us directly.

The post Parasoft Insure++ Is Being Discontinued. Here’s What Replaces It. appeared first on Software Verify.

The standard solution to problems like this is to do the work onto dedicated worker threads. MV’s timeline view does exactly this: a dedicated thread periodically samples memory use and posts a refresh event to the GUI thread when new data is ready. The GUI thread processes the refresh and updates the display.

Avoiding a deadlock

The catch is how you post that event.

From a worker thread you must use PostMessage(), not SendMessage().

Using SendMessage() from a non-GUI thread will cause a deadlock.

What went wrong

Under certain settings and workloads the timeline thread was generating data faster than the GUI thread could process refresh events. The thread kept posting update events. The message queue kept filling with events to process. Eventually the GUI thread was spending all its time processing refresh events and nothing else — including user input. The UI locked completely.

The irony is hard to miss. We added a dedicated worker thread specifically to keep the GUI thread free and responsive. Then we made the GUI thread unresponsive by sending it too many events.

The fix

Two changes.

Before posting a refresh event, check whether one is already pending. If a refresh is already queued, there is no point adding another — the queued one will handle it:

if (!m_bRefreshQueued)
{
    m_bRefreshQueued = true;
    PostMessage(WM_REFRESH_TIMELINE, 0, 0);
}

// In the message handler:

void OnRefreshTimeline()
{
    m_bRefreshQueued = false;
    // ... update the timeline view
}

The second change: check the session state. If the session is in standby — the monitored process has ended, data collection is finished — there is nothing to refresh. Skipping the event in that case cleaned up the post-session screen behaviour:

if (m_session.IsStandby())
    return;

if (!m_bRefreshQueued)
{
    m_bRefreshQueued = true;
    PostMessage(WM_REFRESH_TIMELINE, 0, 0);
}

There was no need to change how we posted the events. We kept the PostMessage() API call.

What to take away

If you have a worker thread posting UI updates, add a pending flag before each PostMessage() call.

Check session or application state too — there is no point refreshing a view that has nothing new to show.

The post We added a thread to keep the GUI responsive. Then we broke it. appeared first on Software Verify.

Crash analysis tools translate those raw memory snapshots into readable call stacks, variable values, and exception details—the information you actually need to fix the bug. With 45% of developers reporting AI-generated code harder to debug according to Stack Overflow’s 2025 survey, these tools are more essential than ever. This guide covers how crash analysis works, the different tool types available, and how to integrate crash analysis into your development workflow.

What are crash analysis tools?

Crash analysis tools are software that developers use to figure out what went wrong when an application crashes. You feed them a crash dump file—a snapshot of your program’s state at the moment it failed—and they show you the call stack, memory contents, and variable values that explain the failure. 

The core functions break down like this:

• Crash dump reading: Opens minidump or full memory dump files captured when your application failed
• Symbol resolution: Translates raw memory addresses into function names and source line numbers
• Call stack extraction: Reconstructs the sequence of function calls leading up to the crash

Without one of these tools, you’re looking at hexadecimal addresses and guessing. With one, you can trace exactly which function failed and often see why.

How crash analysis works

When an application crashes, Windows can capture a snapshot of the process—threads, memory, loaded modules, and the exception that triggered the failure.

Your crash analysis tool reads that snapshot and reconstructs what was happening at the exact moment things went wrong.

Reading debug symbols

Symbols connect compiled code to human-readable names. For minidumps, symbols are stored in the debug information your compiler generates alongside the executable. On Windows, the most common debug information format is PDB (Program Database). Alternative debug information formats are TDS, DWARF, STABS, COFF, Metrowerks and CodeView. Additionally MAP files can sometimes be used to source debug information (this is very compiler/linker dependent and can vary by version of the compiler/linker).

Which format of debug information is available depends on the compiler used to build the software. PDB information is always referenced via a PDB file, which either stores the debug information or serves as a database index pointing to where it is located. TDS data can be stored in separate files or with the executable. STABS, COFF and CodeView data are always stored with the executable.

When you load a crash dump, the tool uses debug information to translate addresses like 0x00007FF6A1B2C3D4 into something like MyApp!ProcessData+0x42. 

If you don’t have the matching debug information, you’ll see raw addresses instead of function names. This is why keeping debug information for every release build matters—you can’t analyze a production crash if you’ve lost the symbols for that build.

PDB files contain identifiers linking them to a specific executable. You can’t just rebuild the binary and use the generated PDB, because it will have its own unique identifier. This is why keeping PDB files for every release build matters.

For kernel dumps, symbol information is always stored in PDB files.

Extracting call stacks

The call stack shows which functions called which, leading up to the crash. Your tool unwinds the stack frames to reconstruct this chain, with the faulting frame at the top.

A typical call stack looks like:

MyApp!ProcessData+0x42
MyApp!HandleRequest+0x1A3
MyApp!WorkerThread+0x8F
kernel32!BaseThreadInitThunk+0x14

Reading from bottom to top, WorkerThread called HandleRequest, which called ProcessData, where the crash occurred. The +0x42 tells you how far into the function the crash happened.

Inspecting memory and variables

Once you’ve found where the crash occurred, you can examine local variables, CPU registers, and memory contents at that location. If a null pointer caused the crash, you’ll see it here. If a buffer overflowed, you can inspect surrounding memory to understand what went wrong.

This is where crash analysis becomes actual debugging—you’re not just finding the crash location, you’re understanding the cause.

Types of crash analysis tools

Different tools fit different workflows. Some developers prefer visual interfaces for exploring unfamiliar crashes. Others want command-line tools they can script into automated pipelines.

GUI-based crash analyzers

GUI tools provide visual interfaces for browsing threads, call stacks, and variables. You can click through stack frames, expand data structures, and visually search memory. They’re well-suited for interactive investigation where you’re exploring a crash you haven’t seen before.

The tradeoff is that GUI tools are harder to automate. If you’re processing one crash dump, a GUI works fine. If you’re processing fifty from an overnight test run, you’ll want something scriptable.

Command-line crash tools

Command-line tools accept arguments and produce text output. You can run them from scripts, capture output to log files, and integrate them into CI pipelines. For batch processing or automated test infrastructure, command-line tools are the practical choice.

Many tools offer both modes—a GUI for interactive work and a command-line interface for automation.

Debugger extensions and plugins

Extensions add capabilities to existing debuggers like WinDbg or Visual Studio. They might provide specialized commands, better visualization for specific data types, or support for particular frameworks. If you already have a debugger workflow you like, extensions let you enhance it without switching tools entirely.

Understanding crash dump formats

Not all crash dumps contain the same information. The format determines how much you can learn—and how large the file will be.

Minidump files

Minidumps are compact files containing thread stacks, loaded module lists, and exception information. They’re typically a few hundred kilobytes to a few megabytes. Windows Error Reporting generates minidumps by default, and most crash reporting systems use this format because the files are small enough to upload quickly.

The tradeoff is that minidumps don’t include full heap contents. You can see the call stack and local variables, but you can’t inspect arbitrary objects allocated on the heap.

Full memory dumps

A full memory dump captures everything—the complete process memory at the moment of the crash. The files can be gigabytes in size, but they let you examine any variable, any heap allocation, any data structure in the process.

When a minidump doesn’t give you enough information, a full dump often will. The challenge is collecting and transferring files that large, especially from production systems or remote machines.

Kernel dumps

Kernel dumps capture operating system state, not just your application. They’re used for driver crashes, blue screens, and other system-level failures—the 2024 CrowdStrike outage, which crashed 8.5 million Windows devices, was diagnosed through kernel dump analysis of an out-of-bounds memory read.

Analyzing kernel dumps requires different tools and symbols—specifically, the Windows kernel symbols from Microsoft’s symbol server.

If you’re debugging application code, you’ll rarely work with kernel dumps. If you’re writing drivers or diagnosing system-level issues, they become essential.

How to perform crash analysis

Here’s a practical walkthrough. The specifics vary by tool, but the process follows the same pattern regardless of which analyzer you use.

1. Collect the crash dump file

Crash dumps come from several sources:

• Windows Error Reporting: Captures dumps automatically for many crashes
• Custom crash handlers: Your application can call MiniDumpWriteDump to create dumps programmatically
• Crash reporting services: Third-party services collect dumps from end users and upload them centrally
• Manual capture: You can attach a debugger and create a dump on demand

However you get the dump, make sure you also have the matching PDB files for the exact build that crashed. A dump without symbols is much harder to analyze.

2. Load symbols and debug information

Before analysis, configure your tool’s symbol path. On Windows, this typically includes your local symbol cache, your build server’s symbol store, and Microsoft’s public symbol server for OS components.

WinDbg

For WinDbg, you’d use the .sympath command:

.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Visual Studio

For Visual Studio, you’d open the Tools > Options dialog box and navigate to Debugging > Symbols, and enable the Microsoft Symbol Servers.

You can see that this user has also added a path to the development version of one of Performance Validator’s projects.

Minidump Browser

For Minidump Browser, you’d open the Settings > Edit Settings dialog box, navigate to Symbol Servers, and click Add… to add a symbol server.

You can see in the image below that the Microsoft Symbol Server has already been added and enabled.

The tool you’re using downloads symbols as needed and caches them locally. First-time analysis of a new build might take a minute while symbols download; subsequent analysis of the same build uses the cache.

3. Locate the faulting thread

Most applications have multiple threads running when they crash. Only one thread triggered the exception. Your tool usually highlights this thread automatically, but you may want to examine the exception record to confirm which thread faulted and what exception occurred.

Common exceptions include access violations (null pointer dereferences, invalid memory access), stack overflows, and unhandled C++ exceptions.

Visual Studio

The threads windows displays the crashed application’s threads, and highlights the crashed thread.

If a filename and line number can be determined for the top of the thread’s callstack, the source code is displayed, highlighting the relevant line.

Minidump Browser

If a loaded minidump contains an exception, the Exception display is shown automatically. This displays the faulting thread id, and thread name, if available.

If a filename and line number can be determined for the top of the thread’s callstack, the source code is displayed, highlighting the relevant line.

4. Examine the call stack

Work through the stack frames from top to bottom. The top frame shows where the crash occurred; the frames below show how execution got there. Look for the transition from your code into library or OS code—that boundary is often where the bug lives.

If frames show only addresses without function names, you’re missing symbols for that module. Check your symbol path configuration.

WinDbg

Use the command k

Visual Studio

The Debug > Call Stack view displays the crashed thread’s callstack.

Minidump Browser

If a loaded minidump contains an exception, the Exception display is shown automatically. The Callstack part of the Exception display shows the crashing callstack.

5. Inspect local variables and registers

Once you’ve found the faulting location, examine the state at that point. Was a pointer null? Did an index exceed array bounds? Was a handle invalid? The answers are usually visible in local variables and CPU registers.

This step often reveals the immediate cause. The root cause—why that variable had a bad value—might require tracing back through earlier code or examining other threads.

WinDbg

Use the command dv to display local variables.

Use the command dv to display local variables. Advanced usage dv /i /t /V. /i indicates local or parameter. /t indicates type. /V indicates memory address.

Use the command kP to display the callstack and parameters passed. This displays results one parameter per line.

Use the command kp to display the callstack and parameters passed. This displays results with all parameters per line.

Use the command kv to display the callstack and the raw values of parameters passed.

Visual Studio

The Debug > Autos view shows you the value of any variables that are in scope.

The Debug > Locals view shows you the value of any local variables and parameters.

The Debug > Watch (1..4) views allow you to specify which variables and parameters you wish to inspect.

Minidump Browser

The Exception view can’t display local variables or parameters, but all the registers from the exception CONTEXT are displayed on the Registers tab.

Automating crash analysis in your workflow

Manual analysis works for occasional crashes. If you’re running automated tests or collecting crashes from production, you’ll want to automate the analysis too.

Running analysis from the command line

Most crash analysis tools support command-line operation. You can pass a dump file path, specify symbol locations, and request specific output—like extracting just the faulting call stack. This lets you script analysis without opening a GUI.

For example, you might write a script that extracts the top ten stack frames from every dump in a directory and writes them to a summary file.

WinDbg

Rather than run windbg.exe from the command line, it is better to run cdb.exe from the command line. This is the console version of WinDbg.

We capture the output of cdb.exe and pipe it to a file.

To run from the command line we use:

This command line loads a minidump e:\buggyApp.dmp and exports it to a txt file.

    cdb.exe -z E:\buggyApp.dmp -y e:\ -c "$$<exportCommands.txt;Q" > e:\buggyApp.txt

The file exportCommands.txt contains the following commands:

Example log file output:

Here is a full list of WinDbg command line options.

Minidump Browser

To run from the command line we use:

This command line loads a minidump e:\buggyApp.dmp and exports it to a html file. The export contains the exception callstack, callstacks for all threads, the loaded modules list and the unloadedmodules list.

    minidumpBrowser_x64.exe /minidump E:\buggyApp.dmp /exportFormat html /exportFileName e\buggyApp.html /exportExceptionCallstack /exportAllThreadsCallstack /exportLoadedModules /exportUnloadedModules

This command line loads a kernel dump e:\buggyDriver.dmp and exports it to a txt file. The export contains bugcheck information, the exception callstack, the loaded modules list and the unloadedmodules list.

    minidumpBrowser_x64.exe /minidump E:\buggyDriver.dmp /exportFormat txt /exportFileName e\buggyDriver.txt /exportBugCheck /exportExceptionCallstack /exportLoadedModules /exportUnloadedModules

Example log file output:

Here is a a full list of Minidump Browser command line options.

Integrating with CI and test suites

When automated tests crash, you can capture dumps and analyze them as part of the build pipeline. The analysis output becomes part of the test report, so developers see the call stack alongside the test failure.

With Splunk research showing downtime costing an average of $9,000 per minute, this approach speeds up debugging significantly. Instead of reproducing the crash locally, you can often diagnose it directly from the CI output.

Generating crash reports automatically

If you’re collecting crashes from production or from large test runs, batch processing becomes practical. You can iterate through a directory of dump files, extract key information from each, and generate summary reports showing patterns—like the same crash occurring across multiple machines or test configurations.

Tip: Software Verify’s minidump tools support both GUI and command-line operation, so you can investigate interactively or automate analysis in your CI pipeline.

How to choose a crash analysis tool

Different compilers produce different debug information formats. A tool built for MSVC symbols may not handle GCC’s DWARF format, and vice versa.

Check that your tool supports the compilers you actually use—whether that’s Visual Studio, C++ Builder, MinGW, Clang, Intel, Delphi, Fortran, or something else.

The following table describes the symbol types supported by each tool.

Minidump Browser is part of a group of related minidump tools to allow you to create, find, manage, explore and visualize minidumps.

FAQs about crash analysis tools

What is the difference between a minidump and a full memory dump?

A minidump contains thread stacks, module lists, and exception data in a compact file.

A full memory dump includes the entire process memory and can be gigabytes in size.

Minidumps are easier to collect and transfer; full dumps let you inspect any heap object.

Can crash analysis tools work without source code?

Yes. You can analyze call stacks and memory without source code, but you’ll want symbol files (PDBs) to see function names instead of raw addresses. Symbols don’t require source code—they’re generated during the build process.

How large are typical crash dump files?

Minidumps are usually a few hundred kilobytes to a few megabytes.

Full dumps can be gigabytes, depending on how much memory the process was using when it crashed.

Do crash analysis tools support both 32-bit and 64-bit applications?

Most modern tools handle both architectures. You’ll want matching symbol files, and some tools require you to use the correct bitness version of the tool itself.

Can developers analyze crashes from release builds?

Yes, if you generate and store PDB files for your release builds.

The common practice is to archive debug information (PDB, TDS, etc) alongside each release so you can analyze crashes from any shipped version.

The post Crash Analysis Tools: Complete Guide for 2026 appeared first on Software Verify.

The use of booleans hinders readability and maintainability of the code.

The use of booleans also allow potential unwanted parameter reordering mistakes to occur.

Some bold claims. I will explain.

Problem 1: Readability and maintainability

If you saw this function call in your code what do you think it would do?

    ok = attachExceptionTracerToRunningProcess(targetProcessId, TRUE, FALSE, _T("d:\\Exception Tracer"));

To find out we’d need to look at the function prototype, or the documentation. Most likely you’re is going to right click in Visual Studio and ask to see the function definition, or a tooltip is going to tell you what the argument names are. 

Here’s the function definition:

    int attachExceptionTracerToRunningProcess(const DWORD  processId,
                                              const bool   processBitDepth,
                                              const bool   singleStep,
                                              const TCHAR* dir);

To use this function you need to pass a process id, a directory path and two boolean values.

We can guess that passing TRUE for singleStep will start Exception Tracer in single stepping mode. But that’s implied, it’s not explicit.

But processBitDepth, what does that do? You’ll need to read the documentation for that : FALSE starts 32 bit Exception Tracer, and TRUE starts 64 bit Exception Tracer.

Reading documentation is not a problem, but it doesn’t make your code very readable does it? It slows things down. 

Swap booleans for enumerations

If we swap the bools for typedef’d enumerations then we get something more readable for the function definition:

    typedef enum _processBitDepth
    {
        PROCESS_BIT_DEPTH_32,
        PROCESS_BIT_DEPTH_64,
    } PROCESS_BIT_DEPTH;

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_NO,
        DO_SINGLE_STEP_YES,
    } DO_SINGLE_STEP;

    int attachExceptionTracerToRunningProcess(const DWORD             processId,
                                              const PROCESS_BIT_DEPTH processBitDepth,
                                              const DO_SINGLE_STEP    singleStep,
                                              const TCHAR*            dir);

Now the function call becomes:

    ok = attachExceptionTracerToRunningProcess(targetProcessId, PROCESS_BIT_DEPTH_64, DO_SINGLE_STEP_NO, _T("d:\\Exception Tracer"));

and the purpose of the function arguments is explicit rather than implied.

Different styles

You don’t need to just use YES and NO, you can use what ever nomenclature feels correct for the situation:

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_NO,
        DO_SINGLE_STEP_YES,
    } DO_SINGLE_STEP;

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_OFF,
        DO_SINGLE_STEP_ON,
    } DO_SINGLE_STEP;

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_DISABLE,
        DO_SINGLE_STEP_ENABLE,
    } DO_SINGLE_STEP;

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_STOP,
        DO_SINGLE_STEP_GO,
    } DO_SINGLE_STEP;

If you really feel TRUE/FALSE are appropriate you can do that as well. Which seems a bit odd, until you see Problem 2 and Problem 3.

    typedef enum _doSingleStep
    {
        DO_SINGLE_STEP_FALSE,
        DO_SINGLE_STEP_TRUE,
    } DO_SINGLE_STEP;

Problem 2: Implicit casting

If you are using bools, many types (char, int, enumerations, etc) can implicitly convert to them without you needing to use a cast statement. This can be convenient, but it’s also an avenue for bugs.

If you’re using typedef’d enumerations, these implicit type conversions fail to compile.

You really want to be explicit about any type conversions.

Problem 3: Unwanted parameter reordering

If you are passing parameters through multiple functions before they finally reach the intended function it’s possible that a future edit (such as refactoring a function’s parameters) may reorder some parameters and a mistake is made during the updating of calls to the refactored function which results in parameters passed to the new function definition have been unintentionally reordered.

This happened to us with some boolean parameters in our code instrumentation library. We discovered the mistake when we switched to using enumerations because now each of these parameters has it’s own type.

Incorrect, but compiles

With the old function definition, this example will compile, but the parameters have been incorrectly switched, leading to incorrect behaviour.

    int attachExceptionTracerToRunningProcess(const DWORD  processId,
                                              const bool   processBitDepth,
                                              const bool   singleStep,
                                              const TCHAR* dir);

    int doStartup(const DWORD  processId,
                  const bool   processBitDepth,
                  const bool   singleStep,
                  const TCHAR* dir)
    {
        int ok;

        ok = attachExceptionTracerToRunningProcess(processId, singleStep, processBitDepth, _T("d:\\Exception Tracer"));
    }

Incorrect, but fails to compile

With the new function definition, this example will fail to compile.

    int attachExceptionTracerToRunningProcess(const DWORD             processId,
                                              const PROCESS_BIT_DEPTH processBitDepth,
                                              const DO_SINGLE_STEP    singleStep,
                                              const TCHAR*            dir);

    int doStartup(const DWORD             processId,
                  const PROCESS_BIT_DEPTH processBitDepth,
                  const DO_SINGLE_STEP    singleStep,
                  const TCHAR*            dir)
    {
        int ok;

        ok = attachExceptionTracerToRunningProcess(processId, singleStep, processBitDepth, _T("d:\\Exception Tracer"));
    }

Making the change

It’s a bit more work to create the enumeration and use it.

With an existing code base it can be time consuming work depending on the number of occurrences of the new enumerated type in your code base.

One type at a time

If you are going to make this change I would recommend changing one parameter type at a time and doing a build after each type change.

This seems more time consuming, but in practice we’ve found it’s easier than making multiple new types and then trying to build and dealing with the chaos that results until you’ve fixed up all the function definitions etc.

If, like us, you’ve got many solutions and many projects in each solution then the quickest way to do these builds is to load the solutions/projects into Visual Studio Project Builder then build all projects of a specific configuration. This saves a lot of time.

Should we change our whole codebase?

There are certainly benefits to doing this. You might find some errors where parameters have been passed in the wrong order.

But for large codebases, changing every boolean use is probably impractical (it will take a long time). The best approach is to change them when you’re editing some code that is using them.

Conclusion

As you can see there are multiple benefits to using enumerations rather than booleans in your code.

You get improved readability and improved type safety.

The post Stop using booleans, they’re hurting your code appeared first on Software Verify.

History

April 2002 to May 2014

All actions required by a Software Verify Tool were performed directly by that tool. 

May 2014

SVL Admin Service provides functionality for various Software Verify tools that these tools cannot do running as a standard user application. 

We wrote about this work as “An end to unwanted UAC prompts”.

February 2024

During February 2024 ago we changed all the access controls on files and pipes that our tools and services use to restrict access to just the users that need to use them.

The problem we wanted to solve

We wanted to prevent the SVL Admin Service and the SVL Build Service from being used by bad actors as a means to attack a computer.

To do this we have:

• Encrypted the communication between any Software Verify tool and the SVL Admin Service.
• Encrypted the communication between Visual Studio Project Builder and the SVL Build Service.
• We’ve also replaced any commands that had the potential for abuse with commands dedicated to specific tasks that can’t be changed to something malicious.
• We’ve also added command verification steps to ensure the appropriate digital signatures are present before we execute them or copy them.

Why we’ve made this change

When we implemented the communication scheme between our tools and the SVL Admin Service we didn’t really think about the security implications as to use these pipes you’d need to know what data we send down them and have access to them as a user.

However, recent attacks on various computer systems, plus studying what malware authors are doing led us to conclude that we should encrypt our comms to make it very hard to monitor the comms between our tools and the service, and also make it very hard to send malicious commands to the service. The services now verify the calling application and all parameters and reject any command where the input parameters cannot be safely verified.

Are my computers at risk?

Software Verify’s footprint worldwide is quite small. Our tools are used worldwide, but we’re only used on developer machines and the occasional customer machine. Our tools aren’t like Notepad++ which is distributed massively around the world. Notepad++ is a great tool and that widespread distribution made it a prime candidate for an attack. This was one of the events which prompted us to improve the security of the SVL Admin Service and SVL Build Service.

Because our tools are not massively distributed, and are more than likely distributed on target machines that are not that valuable to a bad actor (not a C-suite machine), the ROI of attacking our tools now that we’ve made it much harder probably means it’s not worth attacking a machine hoping that our tools are installed on that machine. There are easier, more widely available targets for bad actors to go for.

That said, we strongly recommend updating to the most recent version of the tools released after 18/02/2026.

Please note: The Python tools are legacy tools and cannot be updated. We’ll be releasing some Python capable tools to replace these later this year.

When will this change happen?

The SVL Admin Service will be upgraded when you install any of our tools downloaded from our website after 18/Feb/2026.

Consequences

The consequences of securing the comms between our tools and the SVL Admin Service are that once you’ve upgraded the service any already existing Software Verify tool that needs to use the SVL Admin service will be unable to communicate with the service because it will still be communicating with no encryption.

To fix this you will need to update each tool that uses the SVL Admin Service.

You can do this by:

• Running the tool and doing Check for Updates… from the Software Updates menu
• For free tools: Go to the appropriate software tool page and download the tool again, then install it
• For commercial tools: Login to the authorised downloads area and download the tool and install. Check your email for details

What happens if I continue trying to use a tool without updating it?

The tool you are using may work for many of it’s actions, but any action that requires communicating with the SVL Admin Service will fail.

Any tool that tries to communicate with the encrypted SVL Admin Service without being updated will be shown this message.

If you see this dialog, choose No, then update the tool you are trying to use by downloading a new version from the website.

How do I know which tools to update?

All our tool installers ship with a small utility which will check your machine for previous installs of our tools. These will be checked to determine if they can communicate securely with the SVL Admin Service. If they cannot communicate securely the utility will display a dialog box listing the names of the tool you need to update.

What should I do next?

Find all Software Verify tools installed on your computers and update all of them to the most recent version.

The post Secure Admin Service appeared first on Software Verify.

OK so it’s 2020 and how many people are developing ISAPI extensions? More than you might imagine. Yeah, Ruby on Rails and Rust are all the rage these days, but some people still need to work with ISAPI for a bunch of business reasons.

I recently had to setup IIS 10 with ISAPI on Windows 10. I read a lot of articles on how to do it. None of them were complete, resulting in reading several articles to get something working, so I put this together, mainly for my own benefit (because I really don’t need to spend that much time doing this again!). I’m sharing it so you don’t have to go through this. 

I was trying to get a simple ISAPI extension to work before trying anything else. My guess is most of you are working on legacy code, but a few of you may have been instructed to write a new ISAPI. Here’s a good starting point for a simple ISAPI extension if you haven’t already written one.

Creating an ISAPI extension: https://www.codeproject.com/Articles/1432/What-is-an-ISAPI-Extension

ASP.Net

I’m also going to very briefly mention installing ASP.Net as well.

32 bit ISAPI

There’s an interesting gotcha if you’re developing a 32 bit ISAPI extension. Don’t worry I cover that at the end.

Windows 10 and Windows 11

The instructions in this article work for both Windows 10 and Windows 11. The process is identical on both operating systems.

Installing IIS components

IIS components are installed via the Windows features dialog.

In the Windows 10 search box type “Turn Windows features on and off”, when windows shows you the result that matches press return (or click it).

The feature selection box is displayed. Select the items highlighted red in the image shown below. Click OK.

If you’ve already got partway through configuring IIS Manager and have realised you don’t have all the required components installed that’s OK, just install them and then close IIS Manager and reopen it (I found that if I didn’t do that not all the component parts would show in IIS Manager, making finding (for example) ISAPI and CGI Restrictions impossible.

ASP.Net

If you’re working with ASP.Net, enable the items above that are identified as ASP.NET and the .Net Extensibility options as well.

Configuring IIS Manager

Start Internet Information Services Manager.

In the Windows 10 search box type “Internet Information Services Manager”, when windows shows you the result that matches press return (or click it).

Website

First of all we need a website to work with. If you’ve already got one skip the next few lines.

1. Add a test website. Right click on “Sites” in the left hand menu and choose “Add Website…”

   
   

2. The Add Website dialog is displayed.

   

3. Choose a website name. For example: “test”.
4. Choose a location for the website. For example: C:\testISAPIWebsite
5. Change the port number (just for testing) so that it doesn’t conflict with any other sites you have. For example: 81.
6. Modify the security permissions for the directory you specified in step 4 to allow write and/or execute permissions if you need these permissions. 

Handler Mappings

1. Select the server node on the left hand side and double click click on Handler Mappings on the right hand size.

   

2. The handler mappings are displayed.

   
   
   

3. Right click in empty space and choose “Edit Feature Permissions…”.

   

4. The Edit Feature Permissions dialog is displayed. Enable Read, Script and Execute permissions. When you select the execute check box you’ll notice the entry for ISAPI dlls is added to the displayed Handler Mappings. Click OK.

   
   
   

ISAPI and CGI Restrictions

1. Select the server node on the left hand side and double click click on “ISAPI and CGI Restrictions” on the right hand size.

   

2. Right click in empty space and choose “Add…”.

   

3. Add the path to your ISAPI dll, a description and select the check box so that it is allowed to execute. Click OK.

   
   
   

4. This will place a web.config in the directory that contains the DLL. It will look something like this:

   <?xml version="1.0" encoding="UTF-8"?>
   <configuration>
       <system.webServer>
           <handlers accessPolicy="Read, Execute, Script">
               <remove name="ISAPI-dll" />
               <add name="ISAPI-dll" path="*.dll" verb="*" modules="IsapiModule" scriptProcessor="C:\testISAPIWebsite\validate.dll" resourceType="File" requireAccess="Execute" allowPathInfo="true" preCondition="bitness32" />
           </handlers>
       </system.webServer>
   </configuration>
   

32 bit ISAPI extensions

If your ISAPI is 32 bit you’ll need to enable them. Go to application pools (under the server node), select the application pool that your website is in, right click, choose “Advanced Settings…”.

Change the “Enable 32-Bit Applications” setting to True.

64 bit ISAPI extensions

If your ISAPI is 64 bit you’ll need to ensure that you haven’t got 32 bit extensions enabled. Go to application pools (under the server node), select the application pool that your website is in, right click, choose “Advanced Settings…”. Change the “Enable 32-Bit Applications” setting to False.

Trying out the website

If we assume your ISAPI is called validate.dll you should be able to test your ISAPI in a browser using http://localhost:81/validate.dll?12345678

Authentication problems

If when trying to view your web pages you get strange error messages, select the server node on the left then go to “Feature Delegation” and turn any entries that are “Read only” to “Read/Write”. Then restart the server (top of the right hand bar).

Note that I’m assuming you’re working on a Dev machine. If you’re working on a production machine you might want to be a bit less cavalier than just turning all settings to Read/Write – work through them one at a time to find out what you need and change only that.

Directory Permissions

If you’re having problems with directory permissions that aren’t managed by IIS Manager you should read this article about changing directory permissions for IIS_IUSRS.

Server Errors

If you’re getting error pages from the server describing various server errors you should take a look at Common IIS Server Errors.

The post Setting up ISAPI (and ASP.Net) on IIS 10 appeared first on Software Verify.

This was caused by a failure with an upstream DNS provider.

After waiting for them to fix the problem for far too long we changed DNS providers. 

We started receiving email again during late Sunday evening / early Monday.

If you tried to contact us and got a bounce message, this is the reason why.

Sorry for any inconvenience.

The post Failing email appeared first on Software Verify.

In this article, I’m going to show you how to extract the same data using the Win32 API for use in your application at runtime.

To extract data from a resource in an executable we need some information:

• Executable name.

• Custom resource name.

• Custom resource type name.

In our previous example, the executable name was mvJavaDetective.dll, the custom resource type name was “CLASSFILE” and the custom resource name was “myJavaSpy”.

The API

FindResource

    HRSRC FindResource(HMODULE hModule,
                       LPCTSTR lpName,
                       LPCTSTR lpType);

Call FindResource() to find a resource in an executable and return a resource handle.

The executable is specified using a module handle that represents a module loaded in the current program. If the module is currently loaded you can get a handle to it using GetModuleHandle(). If the module is not currently loaded you can load it with LoadLibrary().

The resource is identified by its custom resource name and custom resource type.

LoadResource

    HGLOBAL LoadResource(HMODULE hModule,
                         HRSRC   hResInfo);

Call LoadResource() to load the resource passings the module handle and the resource handle from FindResource() as parameters.

The returned handle should not be passed to any Global memory function for deallocation.

LockResource

    LPVOID LockResource(HGLOBAL hResData);

Call LockResource() to lock the resource in memory. Pass the handle returned by LoadResource() as the input parameter.

If the call succeeds a pointer to the data represented by the handle is returned.

SizeofResource

    DWORD SizeofResource(HMODULE hModule,
                         HRSRC   hResInfo);

Call SizeofResource() to determine the size of a resource. Pass the module handle and the handle returned from FindResource() as input parameters.

The return value specifies the size of the resource.

Putting it together

In the previous example our example DLL myJavaDetective.dll had a class myJavaSpy.class embedded into a resource with the type “CLASSFILE” and name “myJavaSpy”. I will now show you how to extract the myJavaSpy.class byte codes from the resource.

First we need to get the module handle of the executable (myJavaDetective.dll) containing the myJavaSpy.class. For this example we will assume that myJavaDetective.dll is already loaded into memory.

Call GetModuleHandle() with the name of the DLL holding the resource (“myJavaDetective.dll”). The return value is the module handle.

	HMODULE	hModJavaDetective;

	hModJavaDetective = GetModuleHandle("myJavaDetective.dll");

Once we have the module handle we can attempt to find the resource in the executable. We don’t need to check for a NULL module handle as FindResource() handles that and will return a NULL resource handle (just as it will if the resource is not embedded in the executable).

	jbyte	*classBytes = NULL;
	DWORD	classBytesLength = 0;
	HRSRC	hResource;

	hResource = FindResource(hModJavaDetective,
							 _T("myJavaSpy"),
							 _T("CLASSFILE"));
	if (hResource != NULL)
	{

If FindResource() returns a non NULL handle the resource has been found. Now we must load the resource using LoadResource().

		HGLOBAL	hResourceMemory;

		hResourceMemory = LoadResource(hModJavaDetective, hResource);
		if (hResourceMemory != NULL)
		{

If LoadResource() returns a non NULL handle the resource has been correctly loaded from the executable. This returns a handle of type HGLOBAL. Caution you must not pass this handle to any HGLOBAL related functions such as GlobalFree() or GlobalRealloc() as this handle does not represent a memory allocation. This type is used for backward compatibility with earlier versions of the Windows API.

Before we can use the data we must convert the returned handle into a pointer to the data by calling LockResource(). We also want to know the size of the data in the resource so we call SizeofResource() to determine the size. The pointer returned by LockResource() must not be passed to any memory deallocation functions – it does not need to be deallocated or unlocked.

			void	*ptr;
			DWORD	size;

			ptr = LockResource(hResourceMemory);
			size = SizeofResource(hModInjectedJVMTI, hResource);
			if (ptr != NULL)
			{

If LockResource() returns a non NULL pointer the pointer represents the data embedded in the executable.

Now we have the data we make a copy for our own use and continue as normal. This step is optional, you can use the data directly from the returned pointer if you wish.

				classBytes = new jbyte [size];
				if (classBytes != NULL)
				{
					memcpy(classBytes, ptr, size);
					classBytesLength = size;
				}
			}
		}

		// CAUTION! LoadResource() and LockResource() DO NOT allocate handles or locks, 
		// read the documentation
	}

Now that we have extracted the data from the resource embedded into the executable we can use the data as normal. For this example I will conclude by using the extracted Java class bytescodes to define a Java class in a Java Virtual Machine.

	if (classBytes != NULL)
	{
		// define our class, must have same name as class file bytes
		// pass NULL for the class loader - use default class loader

		jclass		klass = 0;

		klass = jniEnv->DefineClass(SVL_COVERAGE_CLASS, NULL, classBytes, classBytesLength);
		if (klass != 0)
		{
                    // class defined correctly
		}

		// tidy up

		delete [] classBytes;
	}

Wrap up

Now you know how to embed data in an executable at runtime (and after the fact with the utility presented in the previous article) and how to extract data from an executable at runtime. The techniques are quite straightforward to master and allow you to easily embed data for you to use at runtime without worrying about distributing and locating extra data files with your application.

The post How to read embedded data from a resource appeared first on Software Verify.

The Problem – Inaccessible Locations

But what if the crash happens in somewhere that’s hard for you to debug, for example deep inside ExitProcess() or millions of instructions after the last location that you know about that is in your code?

The Solution – Automation

The solution to this problem is a dedicated tool that will single step through your code automatically without requiring you to tell the debugger to single step the next instruction. 

Exception Tracer has a dedicated single-step mode that you can use for this.

However, using Exception Tracer from it’s user interface you can attach to your program, but that doesn’t guarantee single stepping will happen in the right place for you. You could end up single stepping through tens of thousands of lines of code (millions of instructions) that you don’t need to before you get to the part of the program that you know is interesting. You could spend hours waiting for the trace to get to the part of the code that you think is going to be interesting for the purposes of understanding the bug. I know, I’ve waited overnight for single stepping results.

What if you could be more specific about when you choose to attach Exception Tracer you could save hours of time, increasing your productivity?

The solution is to add a single call to your application to launch exception tracer from within your program so that Exception Tracer starts single stepping your application from that exact location.

attachExceptionTracerX64(GetCurrentProcessId());

The function looks like this:

 
static const TCHAR *ET_X86_PATH = _T("C:\\Program Files (x86)\\Software Verify\\ExceptionTracer\\exceptionTracer.exe");
static const TCHAR *ET_X64_PATH = _T("C:\\Program Files (x86)\\Software Verify\\ExceptionTracer\\exceptionTracer_x64.exe");

void attachExceptionTracer_internal(const TCHAR*    pathToExceptionTracer,
                                    DWORD           processId)
{
    int                    b;
    DWORD                  dwCreateFlags;
    STARTUPINFO            startupInfo;    // put info about startup here for CreateProcess()
    PROCESS_INFORMATION    procInfo;        // info about the process is placed here
    CString                theCmdLine;

    theCmdLine.Format(_T("%s /process %d /singleStepRequired:On"), pathToExceptionTracer, processId);

    startupInfo.cb = sizeof(STARTUPINFO);
    startupInfo.lpReserved = NULL;
    startupInfo.lpDesktop = NULL;
    startupInfo.lpTitle = NULL;
    startupInfo.dwX = 0;
    startupInfo.dwY = 0;
    startupInfo.dwXSize = 400;
    startupInfo.dwYSize = 400;
    startupInfo.dwXCountChars = 40;
    startupInfo.dwYCountChars = 25;
    startupInfo.dwFillAttribute = 0;
    startupInfo.dwFlags = STARTF_USESHOWWINDOW;
    startupInfo.wShowWindow = SW_SHOW;
    startupInfo.cbReserved2 = 0;
    startupInfo.lpReserved2 = NULL;
    startupInfo.hStdInput = NULL;
    startupInfo.hStdOutput = NULL;
    startupInfo.hStdError = NULL;

    procInfo.hProcess = NULL;
    procInfo.hThread = NULL;
    procInfo.dwProcessId = NULL;
    procInfo.dwThreadId = NULL;

    dwCreateFlags = NORMAL_PRIORITY_CLASS;

    b = CreateProcess(NULL,                                  // program
                      (TCHAR *)(const TCHAR *)theCmdLine,    // command line
                      NULL,                                  // process attributes (use default)
                      NULL,                                  // thread attributes (use default)
                      FALSE,                                 // inheritance (don't)
                      dwCreateFlags,                         // how to create the process
                      NULL,                                  // environment (use parent's, ie this)
                      NULL,                                  // current directory (same as this process if NULL)
                      &startupInfo,                          // startup info
                      &procInfo);                            // process info (return value)
    if (b)
    {
        WaitForInputIdle(procInfo.hProcess, INFINITE);

        CloseHandle(procInfo.hProcess);
        CloseHandle(procInfo.hThread);
    }
}

void attachExceptionTracerX86(DWORD	processId)
{
    attachExceptionTracer_internal(ET_X86_PATH, processId);
}

void attachExceptionTracerX64(DWORD	processId)
{
    attachExceptionTracer_internal(ET_X64_PATH, processId);
}

There’s also some helper functions to calculate the path to Exception Tracer based on values stored in the registry. All you need to do is:

1. #include attachExceptionTracer.inl into the source file where you want to start Exception Tracer
2. call attachExceptionTracerX86 or attachExceptionTracerX64 as appropriate to start Exception Tracer

Exception Tracer will attach to the application with single stepping enabled and run until the program exits. After the program exits the trace will be processed and then displayed for you to analyse.

The trace shown below shows single stepping into a buffer overrun crash being detected.

The post Debugging a crash with single stepping appeared first on Software Verify.