Frage

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)

War es hilfreich?

Lösung

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.)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top