Solved Explorer.exe repeately crashing in Vista Ultimate x64 [Solved]

Hi all,

A few days ago I began experiencing an odd behavior on my Vista box, every time I opened the start menu and typed something into the search box explorer.exe crashed. Further investigation discovered that was also happening when typing anything into the Run command, into a window address bar and even when typing anything into a New Shortcut address.

NOTE: If you just want to know the solution go to the end of the post .

Using the great tools provided by Sysinternals and by Microsoft, I launched my comprehensive investigation of the problem.

First of all, I set WinDBG to be the default JIT debugger for crashed applications by running .

Next, I caused explorer.exe to crash (which was easy) and analyzed the dump using !analyze -v.

Studying the dump I didn't find any interesting clues except that the call stack of the faulting thread showed that some ole32 and urlmonitor extensions of explorer were there.

So, using Autoruns (by Sysinternals) I first disabled 3rd party extensions like FileZilla shell extension and WinRAR shell extension. Crashed explorer, it restarted and the problem persisted. Next, I disabled all OLE32 and URLMON related extensions, but still explorer was crashing.
Well, if at first you don't succeed - USE MORE EXPLOSIVES!!!

Next, I disabled everything in the Explorer tab of Autoruns hoping that it wouldn't break anything and stop explorer from crashing but to no avail.

Now I got pissed, I launched Process Monitor and Process Explorer, and started crashing the hell out of explorer while comparing the dumps, call stacks, thread IDs, thread methods, file accessed by explorer prior to the crash and registry keys accessed by explorer prior to the crash.

Well, the thread causing the crash was running SHLWAPI.DLL!PathIsRootW and by examining the output of Process Monitor I could see that it was looking for whatever I typed into the address box in PATH folders, favorites and search locations.

Finally, I decided to become BFF with the WinDBG help and find out what else the !analyze extension could offer. Apparently, beside the (very useful) -v switch it also provides the -f and -hang switches that give you more information.

Using these I found that the problem was cause by urlmon.dll, specifically by the ~CUri destructor. From the call stack I could see that ntdll!RtlFreeHeap was the last method to be called, and it was called by the ~CUri destructor and caused a Heap Corruption Exception.

Anyway, since I was really annoyed by this problem for two days by now and in an hour I had to be at a wedding I did something that I regret, I used the first solution that came to mind.

!!! SOLUTION !!!
I deleted the Internet Explorer browsing history (address history).

It solved the problem which probably was caused by some address (and could be a bug in urlmon.dll) but now I can't further investigate to find what was the exact address in the history that caused the crash.

I apologize for the long story but I feel the need to pass the knowledge to others.
There might be some holes in the plot, but that is probably the best I can do at 3:30 AM after a long day.
Hopefully this post will help someone googling for a solution.


And remember:
- Reboot is NOT a solution.
- Complete OS reinstall is NOT as solution.
- Updating Windows and Drivers IS a solution.
- Call Stacks are EVIL!


Best Regards,

DamageJackal


WinDBG !analyze -v -f -hang output for one of the dumps:

0:028> !analyze -f -hang -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: IMAGE_NT_HEADERS32 ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
FAULTING_IP:
ntdll!RtlFreeHeap+d0
00000000`77557960 4c8b6308 mov r12,qword ptr [rbx+8]
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000077557960 (ntdll!RtlFreeHeap+0x00000000000000d0)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 00000a3476b712a8
Attempt to read from address 00000a3476b712a8
FAULTING_THREAD: 000000000000001c
BUGCHECK_STR: HANG
PROCESS_NAME: explorer.exe
ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: 00000a3476b712a8
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- --------------------------
28 41c.3d8 Unknown
WAIT_CHAIN_COMMAND: ~28s;k;;
BLOCKING_THREAD: 00000000000003d8
DEFAULT_BUCKET_ID: APPLICATION_HANG_BusyHang_Memory
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BusyHang_Memory
LAST_CONTROL_TRANSFER: from 000000007733ceaa to 0000000077557960
STACK_TEXT:
00000000`03ffc4c0 00000000`7733ceaa : 00000000`0342ad56 00000000`032e2fa0 00000000`03423c50 00000000`040ad4a0 : ntdll!RtlFreeHeap+0xd0
00000000`03ffc540 000007fe`fe37cbe6 : 00000000`0342ad56 00000000`00000000 00000000`03423c50 00000000`040ad4a0 : kernel32!HeapFree+0xa
00000000`03ffc570 00000000`76f66107 : 00000000`00000000 00000000`00000001 00000000`00000004 00000000`03423ace : ole32!CoTaskMemFree+0x36
00000000`03ffc5a0 00000000`76f66084 : 00000000`00000001 00000000`03423bb0 00000000`040ad4a0 00000000`00000000 : urlmon!CUri::~CUri+0xb7
00000000`03ffc5d0 00000000`76fc5a51 : 00000000`00000000 00000000`03423c50 00000000`00000000 00000000`0342ad56 : urlmon!CUri::`vector deleting destructor'+0x14
00000000`03ffc600 00000000`76f66831 : 00000000`033e6cb0 00000000`03423bb0 00000000`040ad4a0 00000000`032e2e50 : urlmon!TUnknownMTBase<char>::_Release+0x21
00000000`03ffc630 00000000`76fc5961 : 00000000`00000000 00000000`00000000 00000000`040ad4a0 00000000`032e2e50 : urlmon!CHashMapCache::AddItem+0x133
00000000`03ffc670 00000000`76fa3042 : 00000000`00002b80 00000000`03ffc8a0 00000000`0342ad56 00000000`040ad4a0 : urlmon!CreateUriPrivNoCache+0x235
00000000`03ffc700 00000000`76f62a86 : 00000000`00000022 00000000`00000000 00000000`00002b85 00000000`00000000 : urlmon!CreateUriPriv+0x222
00000000`03ffc810 00000000`70f13b06 : ffffffff`fc003698 00000000`03ffc968 00000000`03ffc954 00000000`00000000 : urlmon!CreateUri+0x26
00000000`03ffc860 00000000`70f17716 : 00000000`03ffda28 00000000`0342ace0 00000000`0342ad56 00000000`0342ac70 : ieframe!PrepareURLForDisplayUTF8W+0x46
00000000`03ffc8f0 00000000`70fb8953 : 00000000`0341c440 00000000`03ffda28 00000000`00000000 00000000`03423ac0 : ieframe!CUrlHistory::_GenerateSTATURL+0x137
00000000`03ffd9c0 000007fe`fb52cf7d : 00000000`041ede70 00000000`00000001 00000000`00000000 00000000`00000000 : ieframe!CEnumSTATURL::Next+0x11b
00000000`03ffda00 000007fe`fb52cd7c : 00000000`03324a80 00000000`041ede70 00000000`02bfe698 00000000`00000000 : BROWSEUI!CACLHistory::_GetNextItem+0x93
00000000`03ffeaf0 000007fe`fe71ec82 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000009 : BROWSEUI!CACLHistory::Next+0x28
00000000`03ffeb20 000007fe`fe71eadd : 00000000`00000000 00000000`00000000 00000000`00000000 000007fe`f07a3b2e : SHELL32!CStartMenuQueryFactory::_QueryAutoCompleteSource+0x96
00000000`03ffebc0 000007fe`fe71e8ce : 00000000`02bfe530 00000000`02bfe530 00000000`00000001 000007fe`fe764de7 : SHELL32!CStartMenuQueryFactory::_QueryHistory+0x1b7
00000000`03fffcb0 000007fe`fe717cae : 00000000`00000000 00000000`00000000 00000000`00000010 00000000`02bfe530 : SHELL32!CStartMenuQueryFactory::_QueryInternet+0x179
00000000`03fffd00 000007fe`fe717afe : 00000000`00000000 00000000`02bfe530 00000000`00000000 00000000`00000000 : SHELL32!CStartMenuQueryFactory::_FillResults+0x1d9
00000000`03fffd80 000007fe`fe534681 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : SHELL32!CStartMenuQueryFactory::s_FillResultsThreadProc+0xe
00000000`03fffdb0 00000000`7733495d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : SHLWAPI!WrapperThreadProc+0x116
00000000`03fffea0 00000000`77538791 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`03fffed0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

FOLLOWUP_IP:
urlmon!CUri::~CUri+b7
00000000`76f66107 488364fb5800 and qword ptr [rbx+rdi*8+58h],0
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: urlmon!CUri::~CUri+b7
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: urlmon
IMAGE_NAME: urlmon.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 496f0c22
STACK_COMMAND: ~28s ; kb
BUCKET_ID: X64_HANG_urlmon!CUri::_CUri+b7
FAILURE_BUCKET_ID: APPLICATION_HANG_BusyHang_Memory_cfffffff_urlmon.dll!CUri::_CUri
WATSON_STAGEONE_URL: http://watson.microsoft.com/00047960.htm?Retriage=1
Followup: MachineOwner
---------

Look up "pageheap" if you're interested in reading about a method for debugging heap corruption issues, which is what you had here. One common characteristic of such problems is that the eventual crash occurs after the corrupting code has already finished doing its dirty work, so all you see in the crash dump is a call stack that looks legit, except it's crashing on kernel32!heap* calls.

My guess is that you've got an IE add-on which is a heap corruptor. Dumping the loaded module list (lm) may show you something which has burrowed into the explorer.exe process as an obvious browser add-on.

The -f switch (!analyze) is redundant here because the dump already contains an exception record and the debugger will immediately latch onto that. The exception is an access violation caused by an apparent heap double-free.

"Call stacks are EVIL!" - eh? Every thread in every process running on your machine is in a call stack right this microsecond

H2SO4,

Thanks for the info, I'm sure it will be helpful in the future.
The reason it took me so long to find the solution is because at first all I saw in WinDBG was indications of heap corruption only. At that point I knew, like you said, that there was something messing up the heap and only when it was freed the exception was thrown.

Regarding the module list, I checked every module loaded at that moment (that was after disabling most things loaded by Explorer) and found nothing out of the ordinary.

The fact is that when using !analyze with -hang -f the information given was different and pointed at urlmon.dll as the one responsible for the exception.
If you look at the call stack in the dump I posted earlier you can see that ~CUri is called just before the calls go into the Kernel Mode and there the exception is thrown. The only thing in the way (and in every dump i saw it was there) is OLE32 and !analyze didn't say anything about it.
It couldn't have been an add-on that corrupted the heap because that would cause IE to crash and the problem wouldn't go away after clearing the address history.

I will have to take a deep breath now and restore my system to the day before I fixed the problem to hopefully find the address in history which caused it all.

Another interesting point is that while every address bar in explorer crashed it, when typing in the IE address bar nothing happened.

Oh, and call stacks are evil after looking at them for too long .


DamageJackal