Windows 7 Pro x64 explorer.exe crashing

[Porkrinds]

I have been following the people complaining about this here, as well as on the other forums and searching google day in and day out for a solution to this problem. Here is my exact problem:

Random explorer.exe crashes. Be it the desktop process, or the file manager process. ALSO, when I get these crashes, MMC.EXE will crash when I try to open Event Viewer. Eventually it will stop crashing and I can view everything fine and it's like nothing happened at all. Eventlog is always an error with one of the following, from most often to least often: ntdll.dll, comctl.dll (deep inside the filesystem 'WinSxS'?), msvcrt.dll. 99% of the time it is ntdll.dll as others have reported.

I can always tell when the crash is coming because there is a very small delay and the cursor turns to the busy spinning turquoise circle. Now, the fun part is that I started having this issue in Windows Vista Home Premium x64 before blaming my old install and moving to Windows 7 Professional x64 from MSDN-AA. The crashing happened. I googled to try and fix it, but alas came up empty handed. I re-installed and only installed the basics that were listed as Windows 7 compatible: Intel chipset (it listed Windows 7) and Nvidia current drivers as of today.

The crashing is totally random. I ran several diagnostics:
- sfc /scannow
- antivirus antispyware (even did it on clean install just incase)
- memtest86 overnight, 0 errors
- Seagate disk tools, whatever it's called. Did SMART tests, and both short and long tests.
- Encoding some DVDs into MKV using handbrake. CPU sat taxed %100 both cores for about 5 hours.

Current system setup:
Windows 7 Professional x64 (from MSDN-AA)

MD5: 7b7af5fe3a01e9fd76de4dacb45a796b
SHA1: 50127304441a793ee51b3f501289f6599a559e9f
CRC32: 502c42c1

Dell Inspiron 530
C2D E8400 3.0GHz
Nvidia GTX 260 (Non Core 216)
Foxconn Dell OEM motherboard
4GB DDR2 800MHZ (1GB x 4)
250GB Seagate HDD
Onboard realtek sound
650W Power Supply

I will follow your Windows debugging guide as well on the previous pages and upload the result when I can get explorer to crash again. I can't make it happen... it just happens.

I just wanted to add the "me too" factor.

For what it's worth, I have two other machines that don't exhibit this behavior. Software wise, all machines share the same basic setup.

Dumps attached per discussion HERE. (Note, these are two new dumps, one from the shell process and the other from a seperate file manager explorer.exe process) - yes I tell explorer to start a new process when starting the file manager, etc.

 

[H2SO4]

Dumps attached per discussion HERE. (Note, these are two new dumps, one from the shell process and the other from a seperate file manager explorer.exe process) - yes I tell explorer to start a new process when starting the file manager, etc.

Excellent write-up. Have rep

All 3 of these dumps show a situation called "heap corruption", although the first one is subtly different. "Heap" can be thought of as a region of memory within the process which is allocated to parts of the process as they ask for memory. They must not write over each other's allocations, and it is up to each "part" to ensure that it stays within the confines of what it has allocated for itself.

There are ways to enable special diagnostic heap behaviour, so that the OS pays more attention to who's doing what with heap - at the expense of somewhat degraded performance. That way you can sometimes catch the heap corruptor component in the act, rather than simply witnessing the aftermath later when the corrupted memory is used.

Before we get too carried away, could you please consider temporarily uninstalling 7zip and AVG in order to get rid of their Explorer integration componentry as a test:

Image path: C:\Program Files\7-Zip\7-zip.dll
Image name: 7-zip.dll
Timestamp: Sat Aug 29 20:39:40 2009 (4A99056C)
...
Image path: C:\Program Files (x86)\AVG\AVG8\avgsea.dll
Image name: avgsea.dll
Timestamp: Wed Jul 08 10:22:16 2009 (4A53E6B8)

After that, if the crashes continue, we may need to tweak some settings before generating more dumps.

(BTW, I and others may also be able to help with your MMC crash, but I'd suggest another separate thread for that. The way to get dumps will be a bit different since the process, as I understand it, crashes on startup.)

 

[Porkrinds]

Removed AVG (had to use a special "uninstaller" tool from their website /sigh)
Removed 7zip

I will report back with crash dumps if/when I get the explorer crashing after removing this software.

 

[Porkrinds]

new dump

Here is a dump from a shell crash while right clicking the debug tool from the start menu in order to tell it to run as administrator.

This was after removing 7zip and AVG using their uninstallers.

9/24/09 about 5:15pm EST. I don't know if there are timestamps on the crash logs or not.

 

[H2SO4]

Here is a dump from a shell crash while right clicking the debug tool from the start menu in order to tell it to run as administrator.

This was after removing 7zip and AVG using their uninstallers.

9/24/09 about 5:15pm EST. I don't know if there are timestamps on the crash logs or not.

Yeah, the time of the crash event is recorded, as is the fact that the process was only running for one minute and 39 seconds at the point where this dump was generated

Again, it's a heap corruption problem. This is going into "serious debugging" territory where it's necessary to actually understand the code which is crashing. Given I don't have access to Microsoft's source code, that makes it challenging.

I'm more than happy to continue to work with you on debugging these crashes, but I need to ask you to be prepared to do some fairly esoteric troubleshooting steps, plus you should also realise that we may not be able to find a practical solution based on debugging alone. Right now, your crash patterns are suggesting heap corruption in Microsoft's Explorer code, and that makes me suspect far bigger underlying issues. (Heap corruption of this sort would be rather amateurish, plus it doesn't seem to happen for the vast majority of other Win7 users.)

If you're happy to continue working on it given those caveats, can I please ask you to generate some dumps using a slightly different mechanism:

1) Open a CMD prompt and CD to the folder where you installed the debugging tools.

2) Run this:

cscript adplus.vbs -crash -nodumponfirst -minionsecond -quiet -pn explorer.exe

That will "attach" the debugger to the Explorer process and wait for a crash to occur. When a problem is detected, a dump will be written (along with some other info files) in a new directory under the debugging tools folder ("Crash_Mode__Date_xx-yy-zzzz_-Time..."). Can you please zip up the entire new (dump) folder that's created and upload it here. It may be subtly but importantly different to the previous dumps.

 

[Porkrinds]

Big Dump

Here is the next dump you wanted. This is the shell crashing on a right click.

If you think this is hardware related, I can always do more tests... it's just hard to pinpoint what the issue could be. Maybe your sleuthing will help. Thanks again for your time.

 

[H2SO4]

No probs, I live for this stuff.

Same again that time, supposed heap corruption. I'd like to crank up the OS's level of heap "scrutiny" - make it pay more attention to who's doing what with heap inside the Explorer process. The procedure:

- open elevated (run as admin) CMD prompt
- run this command from the debuggers folder: gflags /i explorer.exe +htc +hfc +hpc +hvc +htd
- restart Explorer at least once because those settings won't take hold otherwise. Either crash it, or terminate and restart it (from task manager).
- Use the same "cscript adplus.vbs..." command line again to attach the debugger to (the new) Explorer, then reproduce the crash once more.
- Upload the subsequent dump.

 

[Porkrinds]

Arghhhh

Ok, I can't get a crash to happen because the slowdown from the debugging is more than I can put up with

I think I can get right click about once every 3-5mins, let alone have a file manager window open which takes 5-10mins just to startup to load as it is. I've tried for about 8 hours to get a crash to happen, and it just won't. Now if I turn off the debugging, I can get a crash to happen in 5-10mins doing various work inside the file manager.

What I can seem to reproduce was the MMC.exe crash. Related? I don't know. I can keep trying since it's the weekend, but if you have any other suggestions to make this a bit more feasible then that would be grand.

 

[H2SO4]

Ok, I can't get a crash to happen because the slowdown from the debugging is more than I can put up with

I think I can get right click about once every 3-5mins, let alone have a file manager window open which takes 5-10mins just to startup to load as it is. I've tried for about 8 hours to get a crash to happen, and it just won't. Now if I turn off the debugging, I can get a crash to happen in 5-10mins doing various work inside the file manager.

What I can seem to reproduce was the MMC.exe crash. Related? I don't know. I can keep trying since it's the weekend, but if you have any other suggestions to make this a bit more feasible then that would be grand.

LOL. OK, so that was a bit ham-fisted on my part

Each of those "flags" corresponds to a specific type of additional heap operation scrutiny by the OS for the process name in question. Their definitions:

htc - Enable heap tail checking
hfc - Enable heap free checking
hpc - Enable heap parameter checking
hvc - Enable heap validation on call
htd - Enable heap tagging by DLL

The more additional scrutiny you specify, the worse the performance. At this stage I'm most interested in HFC because your crashes appear to be caused by something called a "double free" - the same allocation is being erroneously freed twice, as if the app has lost its sync and forgotten about the first time it freed a particular chunk of memory.

Hence, can you please try with just the HFC flag: gflags /i explorer.exe +hfc

To get rid of all additional checks and restore default process behaviour: gflags /i explorer.exe 0xFFFFFFFF

This shouldn't have any bearing on MMC.EXE. Without getting into too much detail, everything we've done so far is going to be specific to Explorer.exe operation, and the OS won't treat MMC.exe any differently. If the MMC crash is not happening - great - it's probably not a conspiracy

 

[Porkrinds]

lol, ok I will reset the flags and give it a whirl.

Yea, it was pretty rough for awhile today. I'd turn off the flags (I used -hfc, etc which seemed to work) and few mins later it would crash. I'd rush to turn it all back on and then nothing. Figures. It's like taking your car to get fixed and the mechanic can't reproduce the error long enough to find out what is the root of the problem.

I'll update this post if I get a good crash dump.

 

[Omikr0n]

For what it's worth, I've been experiencing an IDENTICAL problem since I installed the RTM build of Windows 7 Ultimate x64 on my MacBook Pro last month.

The issue also comes and goes for me. :-/

 

[H2SO4]

For what it's worth, I've been experiencing an IDENTICAL problem since I installed the RTM build of Windows 7 Ultimate x64 on my MacBook Pro last month.

The issue also comes and goes for me. :-/

Can you clarify in what sense do you believe your crash to be identical to the OPs? Is there more to it than the name of the crashing process - Explorer?

 

[Porkrinds]

Sigh

Well, ever since you had me do the gflags /i explorer.exe +htc +hfc +hpc +hvc +htd I have not been able to reproduce the crashing, at all. I can't even get mmc.exe to crash now (i.e. event viewer). I've disabled the debugger and reset the gflags (I did use just +hfc later on like you suggested) back to normal.

I am going to run without debug/gflags for now and wait for another crash to happen. I just can't get it to happen. I have not changed anything since so I don't know what is going on. I've even just reinstalled AVG and 7zip (stable) in effort just to make it crash (incase it was related to those).

If I ever manage to get another crash, I'll fire up the debug stuff and try to reproduce it to get you a dump. So weird. The other day it's crashing on almost every right click and now I can right click until the mouse breaks or my fingers fall off.

I'll be back if I can get you a good dump using the settings you've provided.

update: would running the +hfc and debugger keep the shell from crashing? I can't get it to crash with +hfc and the debug running. /sigh -- it will crash pretty reliably otherwise.

 

[Omikr0n]

For what it's worth, I've been experiencing an IDENTICAL problem since I installed the RTM build of Windows 7 Ultimate x64 on my MacBook Pro last month.

The issue also comes and goes for me. :-/

Can you clarify in what sense do you believe your crash to be identical to the OPs? Is there more to it than the name of the crashing process - Explorer?

I really do mean in almost every sense.

Random Explorer.exe crashes while browsing local drives, network drives, manipulating folders within the Start Menu, etc. No specific rhyme or reason to it. It seems to come and go every few days, and when it happens, MMC also crashes when attempting to launch.

When it is finally launched, all of the errors logged appear to be related to ntdll.dll.

At when I first started experiencing the crashes, I thought it was related to Norton 2010 Beta and browsing network drives, but that appeared to be simply coincidence since that was simply what I did most often. I no longer have Norton installed, and the crashes also happen while browsing local drives.

To compound things further, I am also experiencing intermittent crashes with my KeePass software, with KeePass reporting memory protection errors.

A 24-hr extended memory diagnostic found no evidence of hardware issues.

 

[H2SO4]

update: would running the +hfc and debugger keep the shell from crashing? I can't get it to crash with +hfc and the debug running. /sigh -- it will crash pretty reliably otherwise.

The +hfc thing shouldn't normally alter the frequency of severity of any given crash. Although it's technically possible, it is very rare. The car mechanic analogy you used is a good one - the act of looking at the carburettor shouldn't by itself fix it, unless in doing so the mechanic inadvertantly leaned on something and closed a broken seal

To clarify, are you saying that you can no longer get Explorer (or MMC) to crash at all? Or is it just under +hfc that Explorer doesn't crash, ever?

 

[H2SO4]

Random Explorer.exe crashes while browsing local drives, network drives, manipulating folders within the Start Menu, etc. No specific rhyme or reason to it. It seems to come and go every few days, and when it happens, MMC also crashes when attempting to launch.

If you've been following this thread, you may wish to try using the same debugger steps to generate memory dumps of your own crashes. I'd be happy to take a look at them and hence attempt to verify whether the pattern looks the same as the OP's crashes.

 

[Porkrinds]

Yes, when I set +hfc, I am unable to get explorer or mmc to crash at all. It simply has not crashed with that flag set. If I reset them to default (nothing) then I can get it to crash again after trying for a few minutes.

 

[H2SO4]

Yes, when I set +hfc, I am unable to get explorer or mmc to crash at all. It simply has not crashed with that flag set. If I reset them to default (nothing) then I can get it to crash again after trying for a few minutes.

Interesting. Can you get a similar dump of the crashing MMC process for comparison?

(If it crashes as soon as it starts, one way to get the debugger attached is to first run just MMC.exe, attach the debugger, and only then "add" the event viewer snap-in.)

 

[thefabe]

Dumps attached per discussion HERE. (Note, these are two new dumps, one from the shell process and the other from a seperate file manager explorer.exe process) - yes I tell explorer to start a new process when starting the file manager, etc.

Excellent write-up. Have rep

All 3 of these dumps show a situation called "heap corruption", although the first one is subtly different. "Heap" can be thought of as a region of memory within the process which is allocated to parts of the process as they ask for memory. They must not write over each other's allocations, and it is up to each "part" to ensure that it stays within the confines of what it has allocated for itself.

There are ways to enable special diagnostic heap behaviour, so that the OS pays more attention to who's doing what with heap - at the expense of somewhat degraded performance. That way you can sometimes catch the heap corruptor component in the act, rather than simply witnessing the aftermath later when the corrupted memory is used.

Before we get too carried away, could you please consider temporarily uninstalling 7zip and AVG in order to get rid of their Explorer integration componentry as a test:

Image path: C:\Program Files\7-Zip\7-zip.dll
Image name: 7-zip.dll
Timestamp: Sat Aug 29 20:39:40 2009 (4A99056C)
...
Image path: C:\Program Files (x86)\AVG\AVG8\avgsea.dll
Image name: avgsea.dll
Timestamp: Wed Jul 08 10:22:16 2009 (4A53E6B8)

After that, if the crashes continue, we may need to tweak some settings before generating more dumps.

(BTW, I and others may also be able to help with your MMC crash, but I'd suggest another separate thread for that. The way to get dumps will be a bit different since the process, as I understand it, crashes on startup.)

I never had ie8 crash until i read a thread about how much faster it would run with goggle chromeframe BHO addon installed. Once i did this I then started getting crashes with the heap corruption. so I removed the goggle chrome BHO with hijackthis. and no more heap corruption.

 

[H2SO4]

I never had ie8 crash until i read a thread about how much faster it would run with goggle chromeframe BHO addon installed. Once i did this I then started getting crashes with the heap corruption. so I disabled it and nomore crashing.

In the OP's (Porkrinds's) case it's Explorer.exe that's crashing, not IExplore.exe. His memory dumps don't show much left that's non-default. nVidia control panel stuff, from memory, but that's about it. A curious situation, doubly so because of the recent "heisenbug" development.