WinDbg: Heap corruption detected at 01864DC8
in [MFC]
|
From: Susan Rice on 6 Feb 2007 01:15 I finally got WinDbg to give me some info. I'm new to WinDbg and could use some help deciphering the output. I'm familiar with assembly language. I'm debugging a program for which I have no source code, only the ..exe and related .dll files. It's not my program. This program works fine on some computers, but not others. It consistently bombs on my computer. Took a lot of work just to get this far. Everything is going fine until here, where WinDbg output says: (I'll try to pretty this up as many of these lines are long) ModLoad: 035e0000 03641000 C:\DOCUME~1\DAVIDD~1\LOCALS~1\Temp\ {170B06E4-3387-418B-802A-622144E8A817}\ {2E8EAC71-BFE4-417A-88F0-5A1BDFBCF5D3}\ SPHlpr.dll The program itself later displays a nice though unhappy message saying it crashed in this dll in routine SPHlpr.RemoveUnConnectedDevice with "Error Number: 0x80040707 Description: DLL function call crashed: SPHlpr.RemoveUnConnectedDevice". So here we are loading that dll. I assume Error Number 0x80040707 is a system generated error which means "DLL function call crashed"? It seems to be a popular number in Google for numerous different problems. We quickly load a couple more DLLs: ModLoad: 74c80000 74cac000 C:\WINDOWS\system32\OLEACC.dll ModLoad: 76080000 760e5000 C:\WINDOWS\system32\MSVCP60.dll ModLoad: 74ae0000 74ae7000 C:\WINDOWS\system32\CfgMgr32.dll Heap corruption detected at 01864DC8 Ouch! Now who detected the heap corruption and how? Did WinDbg detect the heap corruption, or did the program itself detect this? I've never encountered this error before. How is heap corruption detected? Of course it all goes downhill from here: (2104.2108): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0001fff8 ebx=01860178 ecx=00020000 edx=00110795 esi=01864358 edi=01860000 eip=7c910de3 esp=00118b30 ebp=00118bec iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 ntdll!wcsncpy+0x354: 7c910de3 663b10 cmp dx,word ptr [eax] ds:0023:0001fff8=???? Sooo, is this saying the exact place the access violation occurred is at this instruction cmp dx,word ptr [eax] in ntdll.dll routine wcsncpy? Was the heap corruption detected when the access violation occurred, and that message goes along with the access violation, or was the heap corruption detected before the access violation, as an ominous precursor to doom? And how was the heap corruption detected? Did the WinDbg debugger detect it? How would I set a breakpoint just before heap corruption? I'm not familiar with WinDbg. This is the first time I've used it. Could I somehow get a breakpoint when CfgMgr32.dll is loaded (the last dll loaded just before heap corruption)? How would I find out what memory to monitor for corruption? Isn't the "heap" dynamically allocated memory that could be anywhere? (Think I'll go to bed and check back later tomorrow.)
From: David Ching on 6 Feb 2007 07:45 "Susan Rice" <srice1(a)cox.net> wrote in message news:Z1Vxh.46323$Ej7.22482(a)newsfe15.phx... > I'm debugging a program for which I have no source code, only the > .exe and related .dll files. It's not my program. This program > works fine on some computers, but not others. It consistently bombs > on my computer. Took a lot of work just to get this far. > .... > Sooo, is this saying the exact place the access violation occurred > is at this instruction > > cmp dx,word ptr [eax] > > in ntdll.dll routine wcsncpy? > .... > How would I set a breakpoint just before heap corruption? I'm not > familiar with WinDbg. This is the first time I've used it. Could I > somehow get a breakpoint when CfgMgr32.dll is loaded (the last dll > loaded just before heap corruption)? > > How would I find out what memory to monitor for corruption? Isn't > the "heap" dynamically allocated memory that could be anywhere? > If you didn't write this code, why are you debugging it? This seems impossible. It's great you know the heap is corrupt, but the question now is, why is CfgMgr32 corrupting it? Obviously it's in a confused state. How much do you know about CfgMgr32? I think it's the DLL responsible for installing new devices. Do you know which function in CfgMgr32 was running at the crash? But even if you did, what can you do about it? Anyway, this has little to do with MFC. You may want to post on microsoft.public.windbg microsoft.public.device.drivers comp.os.ms-windows.programmer.win32 or other newsgroups that CfgMgr32 is discussed (see Google Groups). Good luck, David (MVP)
From: Joseph M. Newcomer on 6 Feb 2007 08:16 See below... On Mon, 05 Feb 2007 22:15:15 -0800, Susan Rice <srice1(a)cox.net> wrote: >I finally got WinDbg to give me some info. I'm new to WinDbg and >could use some help deciphering the output. I'm familiar with >assembly language. > >I'm debugging a program for which I have no source code, only the >.exe and related .dll files. It's not my program. This program >works fine on some computers, but not others. It consistently bombs >on my computer. Took a lot of work just to get this far. > >Everything is going fine until here, where WinDbg output says: >(I'll try to pretty this up as many of these lines are long) > >ModLoad: 035e0000 03641000 C:\DOCUME~1\DAVIDD~1\LOCALS~1\Temp\ > {170B06E4-3387-418B-802A-622144E8A817}\ > {2E8EAC71-BFE4-417A-88F0-5A1BDFBCF5D3}\ > SPHlpr.dll > >The program itself later displays a nice though unhappy message >saying it crashed in this dll in routine >SPHlpr.RemoveUnConnectedDevice with >"Error Number: 0x80040707 Description: DLL function call crashed: >SPHlpr.RemoveUnConnectedDevice". So here we are loading that dll. > >I assume Error Number 0x80040707 is a system generated error which >means "DLL function call crashed"? It seems to be a popular number >in Google for numerous different problems. ***** This looks like some canonical error message from some system component, but it isn't a recognized error code in winerror.h. There is no error code for "DLL function call crashed" in the base Win32 API. What kind of program is calling this? VB? Looks like the kind of error that might come from a __try/__except handler that is catching access faults or the like ***** ***** > >We quickly load a couple more DLLs: >ModLoad: 74c80000 74cac000 C:\WINDOWS\system32\OLEACC.dll >ModLoad: 76080000 760e5000 C:\WINDOWS\system32\MSVCP60.dll >ModLoad: 74ae0000 74ae7000 C:\WINDOWS\system32\CfgMgr32.dll >Heap corruption detected at 01864DC8 ***** Somebody detected heap corruption. Key here is that the heap is damaged, most likely by the DLL that failed, but the DLL that failed might have failed because yet somebody else damaged the heap. ***** > >Ouch! Now who detected the heap corruption and how? Did WinDbg >detect the heap corruption, or did the program itself detect this? ***** The program itself. WinDbg is just reporting the messages from the program ***** >I've never encountered this error before. How is heap corruption >detected? Of course it all goes downhill from here: ***** By massive amounts of error checking. Are you running a debug or release version, by the way? The debug version has even more error checking, but a message this spare looks like it came from the release version ***** > >(2104.2108): Access violation - code c0000005 (first chance) >First chance exceptions are reported before any exception handling. >This exception may be expected and handled. >eax=0001fff8 ebx=01860178 ecx=00020000 edx=00110795 >esi=01864358 edi=01860000 >eip=7c910de3 esp=00118b30 ebp=00118bec iopl=0 >nv up ei pl nz na pe nc >cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >efl=00010206 >ntdll!wcsncpy+0x354: >7c910de3 663b10 cmp dx,word ptr [eax] ds:0023:0001fff8=???? **** I've not used WinDbg for debugging user code. I know that VS has the ability to get into the exception handler logic and intercept exceptions at the point they occur. Check the documentation for exception handling in WinDbg. this is a classic error (access fault, charley-5) Whatever is in eax is being used as a pointer, so somebody clobbered something that is being used in eax. The copy routines are quite tricky, although I'm a little surprised to find wcsncpy in ntdll.dll. But it looks like you passed a bad pointer into a string-copy routine, which is strongly suggestive of a buffer overrun condition somewhere. ***** > > >Sooo, is this saying the exact place the access violation occurred >is at this instruction > >cmp dx,word ptr [eax] > >in ntdll.dll routine wcsncpy? ***** Correct. But of course, this is the consequence of damage that may have happened billions of instructions earlier. ***** > >Was the heap corruption detected when the access violation >occurred, and that message goes along with the access violation, or >was the heap corruption detected before the access violation, as an >ominous precursor to doom? ***** No, the heap corrupt was detected much earlier; then the program continued running, and trying to use the damaged heap, which resulted in the access fault happening much later. ***** > >And how was the heap corruption detected? Did the WinDbg debugger >detect it? ***** No, the heap management routines detected it ***** > >How would I set a breakpoint just before heap corruption? I'm not >familiar with WinDbg. This is the first time I've used it. Could I >somehow get a breakpoint when CfgMgr32.dll is loaded (the last dll >loaded just before heap corruption)? ***** This is hard. First, all you could hope to do here is set a breakpoint before the message that reports the heap corruption, assuming you could find that place. Then, all this tells you is somebody screwed the heap, but not who, or where, it happened. The analogy I use is that you are walking down the street, not watching where you are going, and fall into an open manhole. That's the heap corruption message. It doesn't tell you who removed the cover, or how long ago. ***** > >How would I find out what memory to monitor for corruption? Isn't >the "heap" dynamically allocated memory that could be anywhere? ***** Yes. What I'd do is load the App Veriier (free download from Microsoft), turn on every memory-checking option it has, and run the program. It has a better chance of detecting the exact point where heap corruption occurred. joe ***** > >(Think I'll go to bed and check back later tomorrow.) Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 6 Feb 2007 08:45 The problem is that the module that reports the heap corruption may not be the module that is causing it. It could have been damaged billions of instructions in the past, and this module is the first one that trips over it. joe On Tue, 6 Feb 2007 04:45:47 -0800, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Susan Rice" <srice1(a)cox.net> wrote in message >news:Z1Vxh.46323$Ej7.22482(a)newsfe15.phx... >> I'm debugging a program for which I have no source code, only the >> .exe and related .dll files. It's not my program. This program >> works fine on some computers, but not others. It consistently bombs >> on my computer. Took a lot of work just to get this far. >> >... >> Sooo, is this saying the exact place the access violation occurred >> is at this instruction >> >> cmp dx,word ptr [eax] >> >> in ntdll.dll routine wcsncpy? >> >... >> How would I set a breakpoint just before heap corruption? I'm not >> familiar with WinDbg. This is the first time I've used it. Could I >> somehow get a breakpoint when CfgMgr32.dll is loaded (the last dll >> loaded just before heap corruption)? >> >> How would I find out what memory to monitor for corruption? Isn't >> the "heap" dynamically allocated memory that could be anywhere? >> > >If you didn't write this code, why are you debugging it? This seems >impossible. It's great you know the heap is corrupt, but the question now >is, why is CfgMgr32 corrupting it? Obviously it's in a confused state. How >much do you know about CfgMgr32? I think it's the DLL responsible for >installing new devices. Do you know which function in CfgMgr32 was running >at the crash? But even if you did, what can you do about it? > >Anyway, this has little to do with MFC. You may want to post on > microsoft.public.windbg > microsoft.public.device.drivers > comp.os.ms-windows.programmer.win32 > >or other newsgroups that CfgMgr32 is discussed (see Google Groups). > > >Good luck, >David (MVP) > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 6 Feb 2007 09:15
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:rh1hs21vkdic4vu1nb80j5pukq30i2meti(a)4ax.com... > The problem is that the module that reports the heap corruption may not be > the module that > is causing it. It could have been damaged billions of instructions in the > past, and this > module is the first one that trips over it. Yeah, essentially this is a lot of low-level data and no information. Essentially the PC device manager is screwed up, which we knew even before this multi-day exercise, because Installshield crapped out while dealing with device install. -- David (MVP) |