WinDbg: Heap corruption detected at 01864DC8
in [MFC]
|
From: Susan Rice on 6 Feb 2007 18:22 Ooh there's a WinDbg newsgroup! Perfect! David Ching 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) > >
From: Susan Rice on 6 Feb 2007 18:30 Excellet! App Verifier. Sounds like just what I need (other than a new hobby. I just can't resist an impossible challenge.) Joseph M. Newcomer wrote: > 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: flect on 6 Feb 2007 19:00
> Excellet! App Verifier. Sounds like just what I need (other than a new > hobby. I just can't resist an impossible challenge.) It sounds interesting, but goes into the growing list of programs that require Windows XP. I might have to actually buy XP one of these days! |