-2

So I've run into a seemingly random issue where my software is closing out (almost as if I clicked the X button). After some digging via Windows Event error reporting I realized this was because of a heap corruption.

Unfortunately, the issue seems to only happen under certain unknown conditions. It happens frequently in my production environment (once every 2-3 days, when my customers are using it), but has yet to happen to me while trying to debug the issue on my development environment.

I found this article, on how to find the source of the corruption... but enabling page heaps is causing the software to be unbearably slow (something I can't introduce into the production environment).

Visual Studio - how to find source of heap corruption errors

This is leaving me at a loss on what to do...

Does anyone have any other methods of detecting the source of a heap corruption in a production/release build that doesn't drastically effect performance? Ideally it detects the point of corruption, creates a DMP at the location in the code it occurred, and then continues with normal execution (even if that means crashing/closing out after the DMP is made).

For some context, this software is made using C++ and with Visual Studio 2022.

Rick
  • 421
  • 3
  • 15
  • 1
    [How to create minidump for my process when it crashes?](https://stackoverflow.com/questions/1547211/how-to-create-minidump-for-my-process-when-it-crashes) has some ideas. The accepted answer is how we used to do it when we made Windows applications. Hopefully the stack in the minidump will be useful to narrow things down. – Retired Ninja May 24 '23 at 19:43
  • Logging may also be of some help. – drescherjm May 24 '23 at 20:58
  • There is also [SEH](https://learn.microsoft.com/en-us/cpp/cpp/structured-exception-handling-c-cpp?view=msvc-170) where you can catch OS exceptions and handle instead of exiting your program. – drescherjm May 24 '23 at 21:04
  • Note, if you're using Microsoft compiler, use Release with debug information enabled for debugging\testing environment. One of big pet peeves of debugging programmers about their compiler is that behaviour of program do not match in Debug and Release. E.g. Debug always initializes local variables. It uses different run-time library. It uses allocation which checks bounds. It exports certain programmatically hooks. Nothing of that happens in release – Swift - Friday Pie May 25 '23 at 06:52
  • Hi Rick, if the reply is helpful, you could click '✔' to mark my reply as the accepted answer to change its status to Answered. It will also help others to solve the similar issue. – Yujian Yao - MSFT Jun 01 '23 at 05:42

1 Answers1

-1

If you are sure that the problem is caused by heap corruption and want to collect dump files,I suggest you refer to the following steps.

  1. Download Procdump:
  2. Create a folder where the dump will be stored (e.g. C:\Dumps)
  3. Unzip the compressed package and put procdump.exe in the created directory
  4. Open the Windows command line: Click Start -> Run and type cmd. We recommend running cmd with administrative privileges (right click -> run as administrator), otherwise the utility may not find the required process;
  5. In CMD, use the cd command to switch to the newly created folder:cd <path_to_folder> For example: cd C:\Dumps
  6. Execute the following command to start ProcDump and capture heap corruption events:procdump -ma -h where is the process identifier (PID) of the target process, which can be found in Task Manager. The -ma parameter means to generate a full memory dump, and the -h parameter means to generate a dump file when heap corruption occurs.
  7. Trigger heap corruption: Trigger heap corruption by running the target process or performing specific operations. Once a corruption event occurs, ProcDump will automatically capture and generate a dump file.
  8. Download windbg to open the dump file, then use !analyze -v to analyze it. enter image description here
Yujian Yao - MSFT
  • 945
  • 1
  • 3
  • 9