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.

CdCString::~CdCString()
{
/* The problem */   free(m_pData);
}

I managed to stop the issue by the code

CdCString::~CdCString()
{
    if (m_pData != 0)
    {
       free(m_pData);
       m_pData = 0;
    }
}

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

  1. Windbg heap commands helped a lot here . expecially the !heap etc

Thanks once again. (I may not have this account as I have forgotten the password / email id password as well.)

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top