1

I have an MFC application that has some library references, and it crashes in release mode. The only thing that is visible is the address of where the crash occurs. It is my understanding that this address should fit between two address ranges in the map file, and this is where the code crashed.

Looking at the .map file, there does not seem to be an address that is even close. I read an article written years ago that showed how to resolve the address by either adding or subtracting a value to the disassembly address that Visual Studio shows. I don't remember where the article was, but in any case, the address did not match, or even come close.

Does anyone know of a way to locate where the code fails, by looking at the map file, given the address in visual studio where the code breaks?

desertnaut
  • 57,590
  • 26
  • 140
  • 166
netcat
  • 1,281
  • 1
  • 11
  • 21
  • What about call stack? – Ivan Aksamentov - Drop Apr 15 '16 at 11:16
  • The address reported in the crash is absolute. Map files contain addresses relative to a module. You first need to find the module containing the faulting code (e.g. by calling [GetModuleHandleEx](https://msdn.microsoft.com/en-us/library/windows/desktop/ms683200.aspx)/[GetModuleFileName](https://msdn.microsoft.com/en-us/library/windows/desktop/ms683197.aspx)), to map the crash address to a function. – IInspectable Apr 15 '16 at 11:18
  • This project crashes in release mode when I exit. I don't know where I can put GetModuleHandleEx, as I don't know which code page causes the problem. All I know is that the problem code fires sometime after the frmMain destructor finishes, and before the app returns. This is a rather large code base to attempt to trap the problem area. I believe the problem is when memory is freed, some class has allocated memory incorrectly, and it tries to free something on the heap that is 'out of bounds'. Is there a way to put a try block in MFC that can catch ..., like CLI-enabled code can? – netcat Apr 15 '16 at 13:10
  • Thanks drop, but the call stack only states "> ntdll.dll!77167aa6() " and right below this item, it states " "[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]". Below that are more ntdll addresses which may or may not be correct, per the Frames warning message. – netcat Apr 15 '16 at 13:16
  • 1
    So you can reproduce the issue? In that case you can simply run the application under a debugger, and enable to break into the debugger, when an exception is **thrown**. You also need to load Microsoft's public symbols (see [Debugging with Symbols](https://msdn.microsoft.com/en-us/library/windows/desktop/ee416588.aspx)), and symbols for your application. It is also possible, to install a global unhandled exception filter ([SetUnhandledExceptionFilter](https://msdn.microsoft.com/en-us/library/windows/desktop/ms680634.aspx)) for diagnostics. – IInspectable Apr 15 '16 at 15:17
  • Thanks very much. It only happens in release mode, and not debug mode. It is reproducible, but I don't know how to nail down the place where it fails. I will look into adding debugging symbols, and also installing a global unhandled exception filter. Thanks much. – netcat Apr 15 '16 at 15:20

0 Answers0