0

Sometimes when a certain function is called, I crash and get the following message from Visual Studio: A breakpoint instruction (__debugbreak() statement or a similar call) was executed in myexecutable.exe It only crashes in this way at this particular function and the amount of calls which succeed before an eventual crash vary. I know that this function itself is fine to be called at this time and I always use correct parameters. The function is 3rd party code so I cannot post source code but rest assured, it works correctly in the general sense.

After some research I noticed it might be a memory corruption or memory leakage in my code but since I almost only use modern C++ constructs, that's quite unlikely. Furthermore, I tried to compile my code with SEH exceptions enabled (/EHa) so I wrapped calls to the problematic function in __try and __except(EXCEPTION_CONTINUE_EXECUTION) blocks. I noticed, the __except block was not called though. So, this also did not work and instead I got a crash again but with the message Exception thrown at 0x00007FFF75528A27 (ntdll.dll) in myexecutable.exe: 0xC0000005: Access violation reading location 0x000000E54C390000. Since I don't have the source code of ntdll.dll I can't debug it further but this is a standard Windows DLL so it's unlikely to be broken.

Next I tried enabling memory leak detection like described here. The Output window feedback showed some more clues:

Exception thrown at 0x00007FFF7550F86D (ntdll.dll) in myexecutable.exe: 0xC0000025: Windows cannot continue from this exception.
Exception thrown at 0x00007FFF7550F86D (ntdll.dll) in myexecutable.exe: 0xC0000025: Windows cannot continue from this exception.
Exception thrown at 0x00007FFF7550F86D (ntdll.dll) in myexecutable.exe: 0xC0000025: Windows cannot continue from this exception.
Exception thrown at 0x00007FFF7550F86D (ntdll.dll) in myexecutable.exe: 0xC0000025: Windows cannot continue from this exception.
... many more
Exception thrown at 0x00007FFF7550F839 (ntdll.dll) in myexecutable.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x000000E54C393EB8).
Exception thrown at 0x00007FFF7550F86D (ntdll.dll) in myexecutable.exe: 0xC0000025: Windows cannot continue from this exception.
Exception thrown at 0x00007FFF7550F86D (ntdll.dll) in myexecutable.exe: 0xC0000025: Windows cannot continue from this exception.
Exception thrown at 0x00007FFF75528A27 (ntdll.dll) in myexecutable.exe: 0xC0000005: Access violation reading location 0x000000E54C390000.

Apparently this causes a stack overflow but I don't know why, my code cannot cause a stack overflow at this call site. It also seems like _CrtDumpMemoryLeaks() wasn't called when the crash occurred, so I tried adding calls to _CrtDumpMemoryLeaks() around the spot where it crashes. It detected some leaks but I suppose they were from the 3rd party code due to the nature of the leaked data so it wasn't useful in diagnosing this issue.

Any ideas what the issue could be and how I could research it further? The issue eventually stopped happening (as often) after I minorly refactored my code. I'm really at a loss here, it seems like undefined behavior but I cannot figure out where or how that would be caused. The code at the call site is extremely simple like:

do_command(player, position, index, command_id, nullptr); // int32_t, int32_t, int32_t, CommandType__Enum, MethodInfo*

The crash also seems to happen in release mode but less frequently so it barely caused trouble for endusers.

BullyWiiPlaza
  • 17,329
  • 10
  • 113
  • 185
  • You are dealing with code written by a programmer that did what you're trying to do: catch-em-all exception handling. These are very serious mishaps, clear signs of stack corruption sending code execution into oblivion. But try/except in the code jerking it back into some sort of known state. That it happens over and over again is normal. The debugger break is just one of those mishaps, one that the debugger responds to. Press F5 and it will probably just keep spilling its guts. Very annoying but little you can do about it beyond shopping for another library. – Hans Passant Oct 14 '22 at 11:23

0 Answers0