Slightly new to windbg here
I m working on an application that spawns exe's within.
Our application spawns a Process say A.exe that calls a dll aDll.dll which inturn calls BDll.dll
Sometimes the process appears hung and the customer has to restart the application /
Windbg stack trace reveals the following:
# ChildEBP RetAddr Args to Child
00 0012f9ec 77559d8a 0000000c 00280000 00b52b78 ntdll!_SEH_epilog4
01 0012fa34 77526287 00000012 00b52b70 0012fafc ntdll!RtlpCoalesceFreeBlocks+0x84c (FPO: [Non-Fpo])
02 0012fb2c 775265a6 00b3e090 00b3e098 00b3e098 ntdll!RtlpFreeHeap+0x1f4 (FPO: [Non-Fpo])
03 0012fb4c 760bc3c4 00280000 00000000 00b3e098 ntdll!RtlFreeHeap+0x142 (FPO: [Non-Fpo])
04 0012fb60 70393c1b 00280000 00000000 00b3e098 kernel32!HeapFree+0x14 (FPO: [Non-Fpo])
05 0012fbac 00211060 00b3e098 1002082b 0044cf00 msvcr90!free+0xcd (FPO: [Non-Fpo])
06 0012fbb4 1002082b 0044cf00 00282690 0045c5e0 BDll!CdCString::~CdCString(void)+0x10 (FPO: [0,0,0]) (CONV: thiscall) [d:\code\udstring.cpp @ 63]
07 0012fbd0 703523b1 0044cf00 3dc7c9a8 00000000 Adll!CADllClass::~CADllClass(void)+0x4b (FPO: [0,4,0]) (CONV: thiscall) [d:\code\Adll.cpp @ 123]
08 0012fc14 70352496 00000000 00000000 00000001 msvcr90!_cinit+0xf5 (FPO: [Non-Fpo])
09 0012fc24 70352c90 3dc7c9e8 00000001 0012fc7c msvcr90!_cexit+0xb (FPO: [0,0,0])
0a 0012fc54 70352d5e 70330000 00000000 00000001 msvcr90!__p__tzname+0x106 (FPO: [Non-Fpo])
0b 0012fc68 775289d8 70330000 00000000 00000001 msvcr90!_CRTDLL_INIT+0x1e (FPO: [Non-Fpo])
0c 0012fc88 7752e104 70352d40 70330000 00000000 ntdll!LdrpCallInitRoutine+0x14
0d 0012fd2c 7752e19f 002a28b6 703560ad 00000001 ntdll!LdrShutdownProcess+0x1aa (FPO: [Non-Fpo])
0e 0012fd40 760cbbe6 00000000 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x74 (FPO: [Non-Fpo])
0f 0012fd54 0040220c 00000000 00462c60 002a28a2 kernel32!ExitProcessStub+0x12 (FPO: [1,0,0])
10 0012fef8 0044c47c 00400000 00000000 002a28a2 AExe!WinMain(struct HINSTANCE__ * hInstance = 0x0040220c, struct HINSTANCE__ * hPrevInstance = 0x00000000, char * lpCmdLine = 0x00462c60 "", int iCmdShow = 0n2762914)+0x2cc (FPO: [4,100,4]) (CONV: stdcall) [d:\code\AExe\AExemain.cpp @ 1165]
11 0012ff88 760bed5c 7ffde000 0012ffd4 775337eb AExe!__tmainCRTStartup(void)+0x140 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 574]
12 0012ff94 775337eb 7ffde000 74f05a38 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
13 0012ffd4 775337be 0044c65b 7ffde000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
14 0012ffec 00000000 0044c65b 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])
The Point of AExe where the WinDbg is pointing to is: .
ExitProcess(GetLastError());
return 0;
->Line 1161 }
->Line 1162 else
->Line 1163 {
#endif
->Line 1165 if ((lpCmdLine) && (lpCmdLine[0] != '\0'))
{
The point Windbg in ADLL pointing to is
-> Line 120 // Free allocated resources
-> Line 121 CleanUp();
-> Line 122
-> Line 123 }
The code at the BDll which WinDbg is pointing to is
CdCString::~CdCString()
{
-> Line 63 free(m_pData);
}
Above this the Windbg is moving to FreeHeap etc .. which i do not understand
The datatype is char* m_pData;
Question :- Can anyone put more information on this ? Is this a Heap corruption ? If so , how can I detect the same ? coz this is a HUGE PROGRAM ..
Some action I did was
Action - 1 : In beginning of the DLLMail of the two dll's and the WinMain of the exe I added the following code
{
_CrtSetDbgFlag (
_CRTDBG_ALLOC_MEM_DF |
_CRTDBG_LEAK_CHECK_DF);
_CrtSetReportMode ( _CRT_ERROR,
_CRTDBG_MODE_DEBUG);
and did a release build hoping that this would break on Heap corruption. I am not seeing any break except that the process is hanging.
Action - 2 : The other action is that I attached Aexe.exe on Application Verifier and enabled "Basic"
Action - 3 : A Third action I did was to set gFlag to the following . C:\Program Files\Debugging Tools for Windows (x86)>gflags.exe /p path: SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options ADll.dll: page heap enabled with flags (traces ) AExe.exe: page heap enabled with flags (full traces ) BDll.dll: page heap enabled with flags (traces ) C:\Program Files\Debugging Tools for Windows (x86)>
But still I dont find any break etc ......... I did the above two steps hoping that the code would break into the point where memory corruption occurs Am i doing something wrong?
Is this the matter of some Heap corruption ? IF so how can i detect it (exe or dll) If its not heap corruption, please throw some light on what it is.
Details Platform This issue was reported in 64 Bit but I am able to reproduce it in 32 Bit Windows. Arsenal :- Full source code with symbols / Debugging tools for windows / App verifier
Thanks in Anticipation.
P.S - I ahve changed names of my actual files / functions.
-------------- Some more details on the Heap Corruption from Windbg ------
0012f8cc 10309d3c verifier!VerifierStopMessage+0x1f8 (FPO: [Non-Fpo])
0012f930 10306e4d verifier!AVrfpDphReportCorruptedBlock+0x10c (FPO: [Non-Fpo])
0012f994 10306f95 verifier!AVrfpDphFindBusyMemoryNoCheck+0x7d (FPO: [Non-Fpo])
0012f9b8 10307240 verifier!AVrfpDphFindBusyMemory+0x15 (FPO: [Non-Fpo])
0012f9d4 10309080 verifier!AVrfpDphFindBusyMemoryAndRemoveFromBusyList+0x20 (FPO: [Non-Fpo])
0012f9f0 771e6694 verifier!AVrfDebugPageHeapFree+0x90 (FPO: [Non-Fpo])
0012fa38 771aa13e ntdll!RtlDebugFreeHeap+0x2f (FPO: [Non-Fpo])
0012fb2c 771765a6 ntdll!RtlpFreeHeap+0x5d (FPO: [Non-Fpo])
0012fb4c 769ec3c4 ntdll!RtlFreeHeap+0x142 (FPO: [Non-Fpo])
0012fb60 70123c1b kernel32!HeapFree+0x14 (FPO: [Non-Fpo])
0012fbac 01481060 msvcr90!free+0xcd (FPO: [Non-Fpo])
0012fbb4 10020841 BDll!CdCString::~CdCString+0x10 (FPO: [0,0,0]) (CONV: thiscall) [d:\code\udstring.cpp @ 65]
0012fbd0 700e23b1 ADll!ADllClass::~ADllClass+0x41 (FPO: [0,4,0]) (CONV: thiscall) [d:\code\Adll.cpp @ 123]
0012fc14 700e2496 msvcr90!_cinit+0xf5 (FPO: [Non-Fpo])
0012fc24 700e2c90 msvcr90!_cexit+0xb (FPO: [0,0,0])
0012fc54 700e2d5e msvcr90!__p__tzname+0x106 (FPO: [Non-Fpo])
0012fc68 771789d8 msvcr90!_CRTDLL_INIT+0x1e (FPO: [Non-Fpo])
0012fc88 7717e104 ntdll!LdrpCallInitRoutine+0x14
0012fd2c 7717e19f ntdll!LdrShutdownProcess+0x1aa (FPO: [Non-Fpo])
0012fd40 769fbbe6 ntdll!RtlExitUserProcess+0x74 (FPO: [Non-Fpo])
0:000> !heap -s -v
LFH Key : 0x1290358e
Termination on corruption : DISABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
.01640000 00000002 1024 4 4 2 1 1 0 0
.014f0000 00001002 256 4 256 2 1 1 0 0
.00010000 00008000 64 4 64 2 1 1 0 0
.01f20000 00001002 64 4 64 2 1 1 0 0
.014b0000 00001002 256 4 256 2 1 1 0 0
.024c0000 00001002 64 4 64 2 1 1 0 0
.025d0000 00001002 256 4 256 2 1 1 0 0
-----------------------------------------------------------------------------
I am stuck beyond this ... The windbg is pointing to the same Free statement as i said above. (line numbers may look changed though)
Hello Stack Overflow members,
Looks like the issue has been fixed. The problem was staring right at my face.
I managed to stop the issue by the code
and the hang to the dll doesnt happen any more.
NOTE :- Frankly i am NOT SATISFIED by this fix as I have a gut feeling that the issue lies somewhere deeper within the ADll or even the AExe. I will have to dig out the issue later.
Some lessons i learnt
1 As suggested by paddy I have to go thru the dll best practices document
2 When i use Application verifier with my application - it DOESNT CRASH / HANG. but hangs without it. Therefore another best tool that i used was Debug Diagnostic Tool http://www.microsoft.com/en-us/download/details.aspx?id=26798
Thanks once again. (I may not have this account as I have forgotten the password / email id password as well.)