Jump to content

Need assistance analyzing an Explorer Application Error Minidump


Recommended Posts


Posted

Summary of the crash, same as before:

FAULTING_IP:

+466c530

0466c530 ?? ???

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)

ExceptionAddress: 0466c530

ExceptionCode: c0000005 (Access violation)

ExceptionFlags: 00000000

NumberParameters: 2

Parameter[0]: 00000000

Parameter[1]: 0466c530

Attempt to read from address 0466c530

STACK_TEXT:

WARNING: Frame IP not in any known module. Following frames may be wrong.

0150fa74 7599840c 00000000 02fb3168 0150fad0 0x466c530

0150fa90 75993a2f 00000002 010464f8 00000000 msgina!CDimmedWindow::Create+0x12

0150faa4 7ca78a05 0150fac0 0150fad0 010460f8 msgina!_ShellDimScreen+0x67

0150fcd8 7ca78cca 000100b2 00000002 0150fcfc shell32!CloseWindowsDialog+0x51

0150fce8 010341ff 000100b2 000001fa 010460f8 shell32!ExitWindowsDialog+0x2a

0150fcfc 01026668 000100b2 00000000 00000111 explorer!CTray::_DoExitWindows+0x86

0150fd30 0101c43e 000001fa 00000111 010460f8 explorer!CTray::_Command+0x2da

0150fde8 01001b5c 00010074 00000111 000001fa explorer!CTray::v_WndProc+0x981

0150fe0c 7e418734 00010074 00000111 000001fa explorer!CImpWndProc::s_WndProc+0x65

0150fe38 7e418816 01001b1d 00010074 00000111 user32!InternalCallWinProc+0x28

0150fea0 7e4189cd 000a04a0 01001b1d 00010074 user32!UserCallWinProcCheckWow+0x150

0150ff00 7e418a10 0150ff28 00000000 0150ff44 user32!DispatchMessageWorker+0x306

0150ff10 01001a35 0150ff28 00000000 010460f8 user32!DispatchMessageW+0xf

0150ff44 0100ffd1 00000000 0150ffb4 77f76f42 explorer!CTray::_MessageLoop+0xd9

0150ff50 77f76f42 010460f8 0000005c 00000000 explorer!CTray::MainThreadProc+0x29

0150ffb4 7c80b713 00000000 0000005c 00000000 shlwapi!WrapperThreadProc+0x94

0150ffec 00000000 77f76ed3 0007fdbc 00000000 kernel32!BaseThreadStart+0x37

0:001> u msgina!CDimmedWindow::Create msgina!CDimmedWindow::Create+0x12

msgina!CDimmedWindow::Create:

759983fa 8bff mov edi,edi

759983fc 55 push ebp

759983fd 8bec mov ebp,esp

759983ff 51 push ecx

75998400 51 push ecx

75998401 53 push ebx

75998402 56 push esi

75998403 57 push edi

75998404 8bf1 mov esi,ecx

75998406 ff1528139775 call dword ptr [msgina!_imp__IsDebuggerPresent (75971328)]

0:001> dds msgina!_imp__IsDebuggerPresent

75971328 7c813123 kernel32!IsDebuggerPresent

0:001> u kernel32!IsDebuggerPresent

kernel32!IsDebuggerPresent:

7c813123 e90894e587 jmp 0466c530

0:001> !chkimg -d kernel32

7c813123-7c813128 6 bytes - kernel32!IsDebuggerPresent

[ 64 a1 18 00 00 00:e9 08 94 e5 87 cc ]

6 errors : kernel32 (7c813123-7c813128)

0:001> !chkimg -d user32

7e42384e-7e423852 5 bytes - user32!ChangeDisplaySettingsExA

[ 8b ff 55 8b ec:e9 dd e6 24 86 ]

7e4595bd-7e4595c1 5 bytes - user32!ChangeDisplaySettingsExW (+0x35d6f)

[ 8b ff 55 8b ec:e9 9e 89 21 86 ]

10 errors : user32 (7e42384e-7e4595c1)

Compare that with the non-crashing scenario:

0:000> !chkimg kernel32

0 errors : kernel32

0:000> !chkimg user32

0 errors : user32

0:000> u kernel32!IsDebuggerPresent

kernel32!IsDebuggerPresent:

7c813123 64a118000000 mov eax,dword ptr fs:[00000018h]

So explorer.exe is starting to dim the desktop and msgina.dll makes a call to check if a debugger is attached, this function has been hooked at points to a bogus address, so boom (and reload).

The reloaded version has not had a reason to load the hooking module yet, so now Start / Shut Down has no problem.

I don't like the presence of that module from 1999, we could try renaming the file on disk to make it impossible to load, but there are a few other modules that weren't loaded in the "okay scenario" too:

01c70000 01c73000 wwres_dll Tue Mar 25 13:57:51 2008 (47E8F6CF)

01c80000 01c84000 wwres Tue Mar 25 13:57:52 2008 (47E8F6D0)

01d90000 01df0000 nvapi Wed Dec 05 12:05:30 2007 (475685FA)

03dc0000 03e04000 WdsMktTools Tue Mar 25 13:55:08 2008 (47E8F62C)

044a0000 0455b000 propsys Tue Mar 25 13:42:46 2008 (47E8F346)

04e00000 04e36000 tQuery_dll Tue Mar 25 13:44:04 2008 (47E8F394)

04e40000 04e5a000 MSNLDl Tue Mar 25 13:56:03 2008 (47E8F663)

07380000 073bc000 msshsq Tue Mar 25 13:51:10 2008 (47E8F53E)

0bef0000 0bf27000 mfplat Thu Oct 19 07:47:35 2006 (45371177)

435d0000 43944000 mshtml Wed Apr 23 06:16:29 2008 (480EB81D)

50640000 50649000 wups Tue Jul 31 03:22:19 2007 (46AE8ECB)

58390000 5841a000 l3codeca Mon Apr 14 02:09:56 2008 (4802A0D4)

588a0000 5893f000 mmsys Mon Apr 14 02:10:34 2008 (4802A0FA)

5e760000 5e76a000 perfos Mon Apr 14 02:10:45 2008 (4802A105)

60000000 60185000 tquery Tue Mar 25 13:49:56 2008 (47E8F4F4)

62c70000 62c89000 langwrbk Sat Aug 18 07:34:52 2001 (3B7DFE7C)

73000000 73026000 winspool Mon Apr 14 02:11:19 2008 (4802A127)

73030000 73040000 wzcsapi Mon Apr 14 02:12:38 2008 (4802A176)

73160000 731d7000 oledb32 Mon Apr 14 02:11:01 2008 (4802A115)

73380000 733d7000 zipfldr Mon Apr 14 02:11:25 2008 (4802A12D)

736b0000 736b7000 msdmo Mon Apr 14 02:11:43 2008 (4802A13F)

73760000 737ab000 ddraw Mon Apr 14 02:09:28 2008 (4802A0B8)

73940000 73a10000 d3dim700 Mon Apr 14 02:09:14 2008 (4802A0AA)

73b30000 73b45000 mscms Mon Apr 14 02:11:21 2008 (4802A129)

73bc0000 73bc6000 dciman32 Mon Apr 14 02:09:27 2008 (4802A0B7)

746c0000 746e9000 msls31 Tue Aug 14 03:54:09 2007 (46C10B41)

75350000 75361000 oledb32r Mon Apr 14 02:11:02 2008 (4802A116)

77690000 776b1000 ntmarta Mon Apr 14 02:11:08 2008 (4802A11C)

7e720000 7e7d0000 sxs Mon Apr 14 02:11:06 2008 (4802A11A)

Unloaded modules:

03a70000 03ab6000 audiodev.dll Timestamp: Thu Oct 19 07:47:10 2006 (4537115E)

75a70000 75a91000 MSVFW32.dll Timestamp: Mon Apr 14 02:12:57 2008 (4802A189)

73b50000 73b67000 AVIFIL32.dll Timestamp: Mon Apr 14 02:10:07 2008 (4802A0DF)

5cad0000 5caf7000 shmedia.dll Timestamp: Mon Apr 14 02:11:03 2008 (4802A117)

14070000 1408b000 wmpshell.dll Timestamp: Thu Oct 19 07:48:04 2006 (45371194)

74c80000 74cac000 OLEACC.dll Timestamp: Sat Aug 18 07:33:18 2001 (3B7DFE1E)

07a80000 082c5000 nvcpl.dll Timestamp: Wed Dec 05 11:56:11 2007 (475683CB)

36d30000 36d4b000 MCPS.DLL Timestamp: Thu Apr 19 19:50:46 2007 (4627ABF6)

7dfa0000 7dfb6000 wshext.dll Timestamp: Mon Apr 14 02:12:26 2008 (4802A16A)

605f0000 605f7000 MSISIP.DLL Timestamp: Mon Apr 14 02:12:20 2008 (4802A164)

41f00000 41f07000 asfsipc.dll Timestamp: Wed Nov 10 05:47:13 1999 (3828F8D1)

36d30000 36d4b000 MCPS.DLL Timestamp: Thu Apr 19 19:50:46 2007 (4627ABF6)

We can be smarter in our investigation, however...

Reboot the client and logon, then launch windbg.exe and attach to the process explorer.exe, then enter the following commands in the debugger:

.symfix+ c:\symbols

!sym noisy

.reload /f

ba w4 kernel32!IsDebuggerPresent

g

A breakdown of the commands so you know what they are doing:

".symfix+ c:\symbols" sets up the local symbols cache path and public URL for the symbols server (you don't need this if you have the environment variable _NT_SYMBOL_PATH set)

"!sym noisy" - turns on verbose information when loading symbols, so you get some feedback rather than a flashing cursor

".reload /f" - force a reload of the symbols for all modules (rather than get them when they are needed, saves time later)

"bw w6 kernel32!IsDebuggerPresent" - sets a breakpoint on the IsDebuggerPresent function when something writes to it

"g" - let the debuggee (explorer.exe) resume

Now play with Windows, run various apps, etc. until explorer.exe hangs - you will find the debugger has broken in when something has hooked the function and we can see what it is, if you enter the following command:

.dump /maf c:\explorer.dmp

This will create a full dump of the process - let us have a look at that dump and what the last thing you did was before the hang.

Once the dump is written you can enter "g" again to resume the process to un-hang Explorer.

Posted (edited)
ba w4 kernel32!IsDebuggerPresent
"bw w6 kernel32!IsDebuggerPresent" - sets a breakpoint on the IsDebuggerPresent function when something writes to it

which command should i be entering? 1st one returns a "syntax error: data breakpoint must be aligned" and 2nd just returns a "syntax error"

A quick Google search shows that correct syntax should be ba w4 <target address>. How would I go about finding the target address for "kernel32!IsDebuggerPresent"? Thanks.

Edited by zan2828
Posted

Hmm, if you have symbols configured then the label should be translated to an address for you...

What does it return if you enter:

x kernel32!IsDebuggerPresent

That 'x' command should return the address we want to set the breakpoint at, e.g. on my 64-bit W2K8 server it gives:

0:000> x kernel32!IsDebuggerPresent

00000000`76d1b6b0 kernel32!IsDebuggerPresent (void)

It is the "ba w4" command you want, even though 6 bytes are being patched we can catch a change to any of the first 4 and keep it dword-aligned if that's what is making the debugger unhappy.

Posted (edited)

0:016> x kernel32!IsDebuggerPresent

7c813123 kernel32!IsDebuggerPresent = <no type information>

ba w4 7c813123 also returns a syntax error.

however, inputting "ba w4 7599840c (return address of the function)" is accepted by the debugger. is this correct?

Edited by zan2828
Posted (edited)

doesn't work. however:

0:015> u kernel32!isdebuggerpresent

kernel32!IsDebuggerPresent:

7c813123 64a118000000 mov eax,dword ptr fs:[00000018h]

7c813129 8b4030 mov eax,dword ptr [eax+30h]

7c81312c 0fb64002 movzx eax,byte ptr [eax+2]

7c813130 c3 ret

7c813131 90 nop

7c813132 90 nop

7c813133 90 nop

7c813134 90 nop

0:015> ba w4 7c813123

Data breakpoint must be aligned

^ Syntax error in 'ba w4 7c813123' //doesn't work

0:015> ba w4 7c813129

Data breakpoint must be aligned

^ Syntax error in 'ba w4 7c813129' //doesn't work

0:015> ba w4 7c81312c //works!!

0:015> ba w4 7c813130 //works!!

0:015> ba w4 7c813131

Data breakpoint must be aligned

^ Syntax error in 'ba w4 7c813131' //doesn't work

0:015> bl

0 e 7c81312c w 4 0001 (0001) 0:**** kernel32!IsDebuggerPresent+0x9

1 e 7c813130 w 4 0001 (0001) 0:**** kernel32!IsDebuggerPresent+0xd

would this be useful? only those two addresses would be accepted by the debugger.

Edited by zan2828
Posted

Try this then, we can monitor just a single byte in the 6-byte range:

ba w1 kernel32!IsDebuggerPresent

(I suspect the w4 makes it have to be dword-aligned, so only addresses 7c813128, 7c813124, 7c813120 would work.)

Posted (edited)

Finally, we may have found the culprit.

http://www.adrive.com/public/e62af6a25841d...454a4990ba.html

dump generated after explorer hangs with "ba w1 kernel32!isdebuggerpresent" breakpoint. this happened as explorer was generating thumbnails for a video folder. appears to be consistent too. after explorer reloads and I have the debugger set up again, I can cause a hang browsing through the same folder again. i noticed that explorer was not able to generate a thumbnail for a certain file.

isolating the particular file in its own folder, I can induce a hang just by accessing that folder. however, running with the debugger off, I access the folder, and then shut down, but the error does not occur. so it is still a mystery to me.

I await your findings. Thank you.

Edited by zan2828
Posted (edited)

I found it.

Debugger attached to explorer, prior to viewing folder:

0:016> u kernel32!isdebuggerpresent
kernel32!IsDebuggerPresent:
7c813123 64a118000000 mov eax,dword ptr fs:[00000018h]
7c813129 8b4030 mov eax,dword ptr [eax+30h]
7c81312c 0fb64002 movzx eax,byte ptr [eax+2]
7c813130 c3 ret
7c813131 90 nop
7c813132 90 nop
7c813133 90 nop
7c813134 90 nop
0:016> !chkimg kernel32 -d
0 errors : kernel32

I then input "g" to let the debugee run, and proceed to view the folder, then Ctrl+Break.


0:016> !chkimg kernel32
6 errors : kernel32 (7c813123-7c813128)
0:016> u kernel32!isdebuggerpresent
kernel32!IsDebuggerPresent:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\Combined Community Codec Pack\Filters\Mpeg2DecFilter.ax -
7c813123 e90894ea86 jmp Mpeg2DecFilter!DllUnregisterServer+0x40 (036bc530) //[b]here it is![/b]
7c813128 cc int 3
7c813129 8b4030 mov eax,dword ptr [eax+30h]
7c81312c 0fb64002 movzx eax,byte ptr [eax+2]
7c813130 c3 ret
7c813131 90 nop
7c813132 90 nop
7c813133 90 nop

However, start/shutdown does not crash explorer immediately upon viewing of the folder though. This is what I am confused about. Any ideas?

Edited by zan2828
Posted

Okay, you did the hard work ;)

The hook points to the module which is always missing when explorer calls into the msgina function, which in turn leads to the crash - the module is therefore unloading (without a trace) but also without unhooking itself first - bad.

With the breakpoint on the attempt to write to the IsDebuggerPresent, rather than use "g" to continue it is simpler to look at the threads to see which was doing the write:

The 1-byte write operation we were watching for has taken place, we replaced 0x64 with 0xe9:

0:024> !chkimg -d kernel32

7c813123 - kernel32!IsDebuggerPresent

[ 64:e9 ]

1 error : kernel32 (7c813123)

Looking through the list of threads it was easy to spot the one which has the module you already hinted at (24):

0:024> kvL 50

ChildEBP RetAddr Args to Child

0490e590 04a7f2ac 7c813123 04a4c530 7c813123 Mpeg2DecFilter!DllGetClassObject+0x21235

0490e5a4 04a7f1cd 7c813123 04a4c530 00000006 Mpeg2DecFilter!DllGetClassObject+0x211dc

0490e60c 04a7f452 7c813123 04a4c510 04a4c530 Mpeg2DecFilter!DllGetClassObject+0x210fd

0490e628 04a7f364 04a4c510 04a4c530 00000000 Mpeg2DecFilter!DllGetClassObject+0x21382

0490e640 04a51fa9 04a4c510 04a4c530 04a613a5 Mpeg2DecFilter!DllGetClassObject+0x21294

0490e660 04a6e30b 04a40000 00000000 00000000 Mpeg2DecFilter!DllUnregisterServer+0x5ab9

0490e6a0 04a6e3b2 04a40000 7c90118a 04a40000 Mpeg2DecFilter!DllGetClassObject+0x1023b

0490e6c8 7c91c4da 04a6e395 04a40000 00000001 Mpeg2DecFilter!DllGetClassObject+0x102e2

0490e7d0 7c916351 00000000 c0150008 00000000 ntdll!LdrpRunInitializeRoutines+0x344

0490ea7c 7c9164b3 00000000 00105350 0490ed70 ntdll!LdrpLoadDll+0x3e5

0490ed24 7c801bbd 00105350 0490ed70 0490ed50 ntdll!LdrLoadDll+0x230

0490ed8c 77512485 0490ee08 00000000 00000008 kernel32!LoadLibraryExW+0x18e

0490edb0 775123a1 0490ee08 0490edd4 0490edd8 ole32!CClassCache::CDllPathEntry::LoadDll+0x6c

0490ede0 77511824 0490ee08 0490f0e4 0490ee00 ole32!CClassCache::CDllPathEntry::Create_rl+0x37

0490f02c 77511747 00000001 0490f0e4 0490f05c ole32!CClassCache::CClassEntry::CreateDllClassEntry_rl+0xd6

0490f074 775116a5 00000001 0397da30 0490f09c ole32!CClassCache::GetClassObjectActivator+0x195

0490f0a0 7751120f 0490f0e4 00000000 0490f6d8 ole32!CClassCache::GetClassObject+0x23

0490f11c 775110b3 77607150 00000000 0490f6d8 ole32!CServerContextActivator::CreateInstance+0x106

0490f15c 77511302 0490f6d8 00000000 0490fc24 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7

0490f1b0 77511279 77607154 00000000 0490f6d8 ole32!CApartmentActivator::CreateInstance+0x110

0490f1d0 775120c8 77607154 00000001 00000000 ole32!CProcessActivator::CCICallback+0x6d

0490f1f0 7751207f 7760714c 0490f534 00000000 ole32!CProcessActivator::AttemptActivation+0x2c

0490f228 77511363 7760714c 0490f534 00000000 ole32!CProcessActivator::ActivateByContext+0x42

0490f250 775110b3 7760714c 00000000 0490f6d8 ole32!CProcessActivator::CreateInstance+0x49

0490f290 7751104e 0490f6d8 00000000 0490fc24 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7

0490f4e0 775110b3 77607114 00000000 0490f6d8 ole32!CClientContextActivator::CreateInstance+0x8f

0490f520 77510ef8 0490f6d8 00000000 0490fc24 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7

0490fcd0 77500575 041920f8 00000000 00000401 ole32!ICoCreateInstanceEx+0x3c9

0490fcf8 77500544 041920f8 00000000 00000401 ole32!CComActivator::DoCreateInstance+0x28

0490fd1c 775005b2 041920f8 00000000 00000401 ole32!CoCreateInstanceEx+0x1e

0490fd4c 75f45c70 041920f8 00000000 00000401 ole32!CoCreateInstance+0x37

0490fe00 7486bf25 041920d8 0218d3e8 00000000 devenum!CDeviceMoniker::BindToObject+0x188

0490fe20 748494af 0158f590 0158f884 7e4188a6 quartz!CFilterGraph::OnCreateFilter+0x31

0490fe58 74827810 0045045a 0000040a 0158f590 quartz!CFGControl::CGraphWindow::OnReceiveMessage+0x2c8

0490fe7c 7e418734 0045045a 0000040a 0158f590 quartz!WndProc+0x96

0490fea8 7e418816 748277d2 0045045a 0000040a user32!InternalCallWinProc+0x28

0490ff10 7e4189cd 00000000 748277d2 0045045a user32!UserCallWinProcCheckWow+0x150

0490ff70 7e418a10 0490ff98 00000000 0490ffb4 user32!DispatchMessageWorker+0x306

0490ff80 7486eb0a 0490ff98 7c912d58 00000000 user32!DispatchMessageW+0xf

0490ffb4 7c80b713 00000000 7c912d58 00000000 quartz!ObjectThread+0x95

0490ffec 00000000 7486ea75 000006f8 00000000 kernel32!BaseThreadStart+0x37

Looking at the second frame's return address we can see what address it started at in frame 1:

0:024> u Mpeg2DecFilter!DllGetClassObject+0x211dc-5

Mpeg2DecFilter!DllGetClassObject+0x211d7:

04a7f2a7 e844000000 call Mpeg2DecFilter!DllGetClassObject+0x21220 (04a7f2f0)

04a7f2ac 83c40c add esp,0Ch

Now we can unassemble from this function entry point and see what it does:

0:024> u Mpeg2DecFilter!DllGetClassObject+0x21220 Mpeg2DecFilter!DllGetClassObject+0x21235

Mpeg2DecFilter!DllGetClassObject+0x21220:

04a7f2f0 55 push ebp

04a7f2f1 8bec mov ebp,esp

04a7f2f3 837d1000 cmp dword ptr [ebp+10h],0

04a7f2f7 7506 jne Mpeg2DecFilter!DllGetClassObject+0x2122f (04a7f2ff)

04a7f2f9 8b4508 mov eax,dword ptr [ebp+8]

04a7f2fc 894510 mov dword ptr [ebp+10h],eax

04a7f2ff 8b4d08 mov ecx,dword ptr [ebp+8]

04a7f302 c601e9 mov byte ptr [ecx],0E9h

There is the "put byte value 0xe9 into address pointed to by register ECX" instruction, where ECX was set up to point to the IsDebuggerPresent function.

The entire function just seems to replace a single byte at a time, so must be called 6 times to place the hook - I assume this is to avoid detection by containing the offset as a string of bytes, this is all of it:

0:024> u Mpeg2DecFilter!DllGetClassObject+0x21220 04a7f32c

Mpeg2DecFilter!DllGetClassObject+0x21220:

04a7f2f0 55 push ebp

04a7f2f1 8bec mov ebp,esp

04a7f2f3 837d1000 cmp dword ptr [ebp+10h],0

04a7f2f7 7506 jne Mpeg2DecFilter!DllGetClassObject+0x2122f (04a7f2ff)

04a7f2f9 8b4508 mov eax,dword ptr [ebp+8]

04a7f2fc 894510 mov dword ptr [ebp+10h],eax

04a7f2ff 8b4d08 mov ecx,dword ptr [ebp+8]

04a7f302 c601e9 mov byte ptr [ecx],0E9h

04a7f305 8b5508 mov edx,dword ptr [ebp+8]

04a7f308 83c201 add edx,1

04a7f30b 895508 mov dword ptr [ebp+8],edx

04a7f30e 8b4510 mov eax,dword ptr [ebp+10h]

04a7f311 83c005 add eax,5

04a7f314 8b4d0c mov ecx,dword ptr [ebp+0Ch]

04a7f317 2bc8 sub ecx,eax

04a7f319 8b5508 mov edx,dword ptr [ebp+8]

04a7f31c 890a mov dword ptr [edx],ecx

04a7f31e 8b4508 mov eax,dword ptr [ebp+8]

04a7f321 83c004 add eax,4

04a7f324 894508 mov dword ptr [ebp+8],eax

04a7f327 8b4508 mov eax,dword ptr [ebp+8]

04a7f32a 5d pop ebp

04a7f32b c3 ret

So this isn't by mistake, the module is most definitely doing a deliberate hook in a manner that is trying to avoid detection, for what reason I couldn't say.

Take a look at the top few frames of the call stack again:

0490e590 04a7f2ac 7c813123 04a4c530 7c813123 Mpeg2DecFilter!DllGetClassObject+0x21235

0490e5a4 04a7f1cd 7c813123 04a4c530 00000006 Mpeg2DecFilter!DllGetClassObject+0x211dc

0490e60c 04a7f452 7c813123 04a4c510 04a4c530 Mpeg2DecFilter!DllGetClassObject+0x210fd

0:024> ln 7c813123

Exact matches:

kernel32!IsDebuggerPresent (void)

0:024> ln 04a4c530

(04a4c4f0) Mpeg2DecFilter!DllUnregisterServer+0x40 | (04a5e050) Mpeg2DecFilter!DllCanUnloadNow

0:024> lmvm Mpeg2DecFilter

start end module name

04a40000 04ab1000 Mpeg2DecFilter (export symbols) Mpeg2DecFilter.ax

Loaded symbol image file: Mpeg2DecFilter.ax

Image path: C:\Program Files\Combined Community Codec Pack\Filters\Mpeg2DecFilter.ax

Image name: Mpeg2DecFilter.ax

Timestamp: Thu May 17 11:37:09 2007 (464C2245)

CheckSum: 00076973

ImageSize: 00071000

File version: 1.0.0.3

Product version: 1.0.0.3

File flags: 0 (Mask 17)

File OS: 4 Unknown Win32

File type: 2.0 Dll

File date: 00000000.00000000

Translations: 0409.04b0

CompanyName: Gabest

ProductName: Mpeg2Dec Filter

InternalName: Mpeg2Dec Filter

OriginalFilename: Mpeg2DecFilter.ax

ProductVersion: 1, 0, 0, 3

FileVersion: 1, 0, 0, 3

FileDescription: MPEG-1/2 Decoder Filter for DirectShow

LegalCopyright: Copyright © 2003-2006 Gabest

Comments: http://gabest.org/

When explorer.exe does not crash, this module is still loaded and so the IsDebuggerPresent hook can jump into this module without causing an exception - if it has been unloaded then it goes boom, and that's the only reason we spot this dodgy behaviour.

Posted (edited)

Impressive. I think I can manage from here.

I am very grateful for all your help, and I have learned a lot as well from your methodical and detailed posts. If you don't mind me asking, do you do this sort of work for a living, or is it simply a hobby?

Edited by zan2828
Posted

Attach to your process using Windbg.

Click Debug / Event Filters.

Select the 6th entry in the list "Unload module", click the radio button "Enabled".

Click Close, then enter "g" to let the debuggee resume.

Debugger will now break in whenever a module unloads.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...