7

In an effort to track down some hard to reproduce crashes I've configured the UnhandledExceptionFilter to create mini-dump files as described here: Debugging Custom Filters For Unhandled Exceptions and Effective Minidumps

The dumps are being successfully captured but I'm not having much luck interpreting the stack information. In the hope that someone else will have experienced something similar I'll provide as many details as I can below. Sorry if this question ends up being a little verbose as a result.

Visual Studio provides the following dump summary:

Dump Summary
------------
Dump File:  MiniDump.dmp
Last Write Time:    15/08/2012 22:07:22
Process Name:   Server.exe : C:\Project\Server.exe
Process Architecture:   x86
Exception Code: 0xC0000005
Exception Information:  The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Heap Information:   Not Present

System Information
------------------
OS Version: 6.1.7601
CLR Version(s): 

Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
Server.exe  C:\Project\Server.exe   1.0.0.1
ntdll.dll   C:\Windows\SysWOW64\ntdll.dll   6.1.7601.17725
kernel32.dll    C:\Windows\SysWOW64\kernel32.dll    6.1.7601.17651
KERNELBASE.dll  C:\Windows\SysWOW64\KERNELBASE.dll  6.1.7601.17651
mysqlpp_d.dll   C:\Projects\Ken11\bin\debug\mysqlpp_d.dll   0.0.0.0
wsock32.dll C:\Windows\System32\wsock32.dll 6.1.7600.16385
ws2_32.dll  C:\Windows\SysWOW64\ws2_32.dll  6.1.7601.17514
msvcrt.dll  C:\Windows\SysWOW64\msvcrt.dll  7.0.7601.17744
libmySQL.dll    C:\Projects\Ken11\bin\debug\libmySQL.dll    0.0.0.0
user32.dll  C:\Windows\SysWOW64\user32.dll  6.1.7601.17514
advapi32.dll    C:\Windows\SysWOW64\advapi32.dll    6.1.7601.17514
msvcp90d.dll    C:\Projects\Ken11\bin\debug\Microsoft.VC90.DebugCRT\msvcp90d.dll    9.0.21022.8
msvcr90d.dll    C:\Projects\Ken11\bin\debug\Microsoft.VC90.DebugCRT\msvcr90d.dll    9.0.21022.8
mfc90d.dll  C:\Projects\Ken11\bin\debug\Microsoft.VC90.DebugMFC\mfc90d.dll  9.0.21022.8
dbghelp.dll C:\Windows\System32\dbghelp.dll 6.1.7601.17514
mswsock.dll C:\Windows\System32\mswsock.dll 6.1.7601.17514
wininet.dll C:\Windows\SysWOW64\wininet.dll 8.0.7601.17785
rasman.dll  C:\Windows\System32\rasman.dll  6.1.7600.16385
devobj.dll  C:\Windows\SysWOW64\devobj.dll  6.1.7601.17621

Looking at the stack of the thread where the exception occurred we get the following extremely short call stack:

    msvcr90d.dll!6d69f824()     
    [Frames below may be incorrect and/or missing, no symbols loaded for msvcr90d.dll]  
--> Server.exe!CServer::LoadPageList()  Line 269 + 0x28 bytes   C++
    cccccccc()

All the correct threads in the application have nice clean stacks showing calls all the way back to __RtlUserThreadStart E.g:

mswsock.dll!_WSPRecv@36()  + 0x34ff bytes   
ws2_32.dll!_WSARecv@28()  + 0x71 bytes  
wsock32.dll!_recv@16()  + 0x33 bytes    
>libmySQL.dll!008aaa2f()    
[Frames below may be incorrect and/or missing, no symbols loaded for libmySQL.dll]  
libmySQL.dll!008aac0d()     
libmySQL.dll!008a34d7()     
libmySQL.dll!008a30d2()     
libmySQL.dll!0084be35()     
libmySQL.dll!00851572()     
libmySQL.dll!00851c2b()     
Server.exe!CServer::logStatusToDB(AsynchStatus_T * pStatus=0x04f18170)  Line 1717   C++
Server.exe!CServer::checkStatus(AsynchStatus_T * pStatus=0x04f18170)  Line 2145 C++
Server.exe!CThread::ControllingFunction(void * lpParameter=0x03fffe08)  Line 1280 + 0xf bytes   C++
kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes    
ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes   
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

How could the lower portion of the crashed thread's stack get replaced by 0xCCCCCCCC?

For completeness here is the disassembly of the frame Server.exe!CServer::LoadPageList() Line 269 + 0x28 bytes 

00453217  mov         byte ptr [ebp-4],0  
0045321B  mov         esi,esp  
0045321D  lea         ecx,[ebp-104h]  
00453223  call        dword ptr [__imp_ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > (6DA994h)]  
00453229  cmp         esi,esp  
0045322B  call        _RTC_CheckEsp (690D20h)  
00453230  mov         dword ptr [ebp-4],0FFFFFFFFh  
00453237  mov         esi,esp  
00453239  lea         ecx,[ebp-20h]  
0045323C  call        dword ptr [__imp_ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > (6DA994h)]  
00453242  cmp         esi,esp  
00453244  call        _RTC_CheckEsp (690D20h)  
00453249  push        edx  
0045324A  mov         ecx,ebp  
0045324C  push        eax  
0045324D  lea         edx,[ (45327Ch)]  
00453253  call        _RTC_CheckStackVars (690D50h)  
00453258  pop         eax             <<<=== exception refers to this line
00453259  pop         edx  
0045325A  mov         ecx,dword ptr [ebp-0Ch]  
0045325D  mov         dword ptr fs:[0],ecx  
00453264  pop         ecx  
00453265  pop         edi

Update

Completely forgot to include the function source (thanks Joachim):

void CServer::LoadPageList()
{
    CString header;
    header.Format("Accept: text/plain, */*; q=0.01\r\n");
    _pSession->setHttpHeader (header);
    _pSession->ReadPage (_T("/Pages"), true);
    SaveTimeStampedFile ("Pages.txt");
}

The strange thing is that all of the operations in the function LoadPageList complete successfully, the crash seems to happen after the string's destructor is called just before returning from this stack frame.

chillitom
  • 24,888
  • 17
  • 83
  • 118
  • 1
    Well I think the actual C++ source of `CServer::LoadPageList` instead of an assembler dump would be more helpful, and especially if it contained a hint to which line is number 269. – Some programmer dude Aug 16 '12 at 13:20
  • thanks Joachim, have updated to include the source – chillitom Aug 16 '12 at 13:31
  • what is _pSession??? Seems this has corrupted the stack `_pSession->ReadPage (_T("/Pages"), true);` – perilbrain Aug 16 '12 at 13:38
  • it's a clunky http client I've inherited - can i presume that if the stack had corrupted before LoadPageList it wouldn't have made it this far? I'll treat ReadPage as the prime candidate, is there any way I can create an exception as the point of corruption as opposed to after the fact? – chillitom Aug 16 '12 at 14:09
  • 2
    If something has completely smashed the stack, the reference to `LoadPageList` may be a red herring, unfortunately. The `cccccccc` is often used as memory filler to ensure a crash if the program jumps into the unknown, which suggests that what you're looking at isn't the "real" stack, just random memory. Check if the stack pointer (`esp`) makes sense. – molbdnilo Aug 16 '12 at 15:01
  • odd, the ESP points to what looks like code but none of the loaded modules seem to be responsible for that address range, no symbols or source load for it either – chillitom Aug 16 '12 at 15:23
  • It smells like a buffer overflow. But anyway, ESP should not point to code, unless the buffer overflow put code on the stack (viruses and worms have been doing that ever since the Morris worm, that's why the stack is no longer executable by default). – Michael Veksler Jul 28 '18 at 07:10

1 Answers1

0

In my case, this silent crash (viewed in Minidump) was caused by Data Execution Prevention (DEP) and adding to exceptions removed error.

Reminder for random visitors - be careful, probably scan first on VirusTotal or similar site what you are adding to exceptions.

halt9k
  • 527
  • 4
  • 13