Windows Explorer has stopped responding

[sphericalpuma]

In event viewer this is what's listed for general on the error:

Faulting application name: Explorer.EXE, version: 6.1.7600.16404, time stamp: 0x4a765771
Faulting module name: ntdll.dll, version: 6.1.7600.16385, time stamp: 0x4a5be02b
Exception code: 0xc0000005
Fault offset: 0x0000000000051da0
Faulting process id: 0xca4
Faulting application start time: 0x01ca568eeafa0b70
Faulting application path: C:\Windows\Explorer.EXE
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 04186864-c29d-11de-990a-0019156d93b5

Then under details:

Explorer.EXE


6.1.7600.16404


4a765771


ntdll.dll


6.1.7600.16385


4a5be02b


c0000005


0000000000051da0


ca4


01ca568eeafa0b70


C:\Windows\Explorer.EXE


C:\Windows\SYSTEM32\ntdll.dll


04186864-c29d-11de-990a-0019156d93b5
I've seen that others are having similiar problems, but mine were occuring when i'd empty the recycle bin, or heading into explorer. so I wasn't sure if it was the same deal. Can anyone help

 

[H2SO4]

There are any number of reasons why a crash like that may occur, and most are related to the addition of 3rd-party code which runs "inside" the Explorer process - right-click menu context handlers and the like.

If you go through the following to obtain a memory dump generated during the crash, someone may be able to tell you why Explorer is behaving that way on your machine:

1) Download and install either the 32-bit or the 64-bit "Debugging Tools" package, depending on your OS type: Debugging Tools for Windows - Overview

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

3) Run this command:

cscript adplus.vbs -crash -noDumpOnFirst -miniOnSecond -quiet -pn explorer.exe

4) Reproduce the Explorer crash.

5) Find the new folder in that same location with a DMP (memory dump) file. Zip up that entire folder and upload it here.

 

[H2SO4]

View attachment 33260

This is the folder

Are you quite sure Explorer crashed after you did all that? Can you see a new event log entry corresponding to the last crash which happened after you issued the "cscript adplus.vbs..." command?

 

[H2SO4]

Hmm it's not causing a crash in explorer.exe when I run that command

Are you saying that you can't seem to repro the crash after you run that command?

(The command by itself won't cause/reproduce another crash instance. It just sits there and waits for the monitored process to crash again, so that it can produce a (mini) memory dump.)

 

[usasma]

I'll give it a shot, but you'd be better off waiting for H2SO4 - I don't have any experience with user-mode dump files.

 

[usasma]

Sorry, but I just can't make much out of the download. I wonder about your Trend Micro installation - so you may want to uninstall it to see if that helps. But that's just a guess on my part.

 

[H2SO4]

I managed to recreate the crash, but could not compress the folder enough to host it on sevenforums, so I've uploaded it onto megaupload.com

I hope someone can take a look at these files and figure out what is going on.

File Location: MEGAUPLOAD - The leading online storage and file delivery service
Link Password: pumadebug

Hmm, another heap corruption crash. I can't precisely tell you the cause based on that dump, but there are two possible approaches from this point onwards which will almost certainly lead to a resolution:

A) Remove the following Explorer add-ons one-at-a-time and test whether the symptom is reproducible without each one of them in turn: "FileLock", nvidia shell extensions, Bonjour, WinRAR (it has added a context handler), Trend Micro AV. My gut feeling tells me to blame FileLock as the most likely offender, but that's just personal bias. It could be any of them.

OR

B) Enable a special mode of operation specifically for the Explorer process, in the hope that the next heap corruption occurrence will be caught as it happens, rather than later on down the track when the bad data is accessed. The procedure:

1) On an elevated (run as admin) CMD prompt: gflags /p /enable Explorer.exe /full

2) Reboot or restart Explorer (same effect).

3) Once again, run the "cscript adplus.vbs...." command from before.

4) Reproduce the Explorer crash again.

5) Find the new DMP file, hopefully the small one with "2nd_chance" in its name, and upload just that for analysis.

 

[MrPinguy]

Sorry to post in this thread but i have the same problem with Win 7 Pro (x64)
If you don't mind could you take a look and help please?
Thank you for your time.

I did the same thing posted on the second post with the the debugger, here's the resulting files.

MEGAUPLOAD - The leading online storage and file delivery service

Thanks.

 

[sphericalpuma]

I managed to recreate the crash, but could not compress the folder enough to host it on sevenforums, so I've uploaded it onto megaupload.com

I hope someone can take a look at these files and figure out what is going on.

File Location: MEGAUPLOAD - The leading online storage and file delivery service
Link Password: pumadebug

Hmm, another heap corruption crash. I can't precisely tell you the cause based on that dump, but there are two possible approaches from this point onwards which will almost certainly lead to a resolution:

A) Remove the following Explorer add-ons one-at-a-time and test whether the symptom is reproducible without each one of them in turn: "FileLock", nvidia shell extensions, Bonjour, WinRAR (it has added a context handler), Trend Micro AV. My gut feeling tells me to blame FileLock as the most likely offender, but that's just personal bias. It could be any of them.

OR

B) Enable a special mode of operation specifically for the Explorer process, in the hope that the next heap corruption occurrence will be caught as it happens, rather than later on down the track when the bad data is accessed. The procedure:

1) On an elevated (run as admin) CMD prompt: gflags /p /enable Explorer.exe /full

2) Reboot or restart Explorer (same effect).

3) Once again, run the "cscript adplus.vbs...." command from before.

4) Reproduce the Explorer crash again.

5) Find the new DMP file, hopefully the small one with "2nd_chance" in its name, and upload just that for analysis.

Recreated the crash and dmp file (one that begins with 2nd chance) is attached

 

[sphericalpuma]

Did the process again just in case you needed a recent file.

 

[H2SO4]

Did the process again just in case you needed a recent file.

Thanks mate. I'm looking at it, but it's complex. Gimme some time please, and I'll get back to you.

 

[sphericalpuma]

I can't begin to express how thankful I am for you taking the time out of your life to look at this. Nice to know the quality of members here on this forum.

 

[H2SO4]

Short version: I don't say this lightly, but I think your issue may be an actual bug in Explorer. If you haven't already done so, I would suggest bringing this to Microsoft's attention. Their more senior support engineers will probably find those latest dumps interesting.

====================================
Detail: I've noticed previously that quite a few of the "my Explorer is crashing" reports come in the form of a problem known as heap corruption. As the name implies, a memory "heap" is a process-specific region of memory which the process (app) can draw from as necessary. Different parts of the process/app will have different memory requirements, but it's all OK as long as they don't stomp on each other's heap allocations.

Explorer is just an app as far as the OS is concerned (it's not deemed a critical process). Internally, it utilises the heap memory mechanism. However, Explorer is also a container of sorts for 3rd-party add-ons such as context menu handlers and other code whose purpose is to extend standard Explorer functionality. Most Explorer crashes are in fact caused by such add-ons.

In this case, the initial dump looked like garden variety heap corruption - something (inside Explorer) had corrupted heap memory. That's not an uncommon crash pattern, but the problem is that it's difficult or impossible to tell who/what actually corrupted the heap by the time the corrupted memory causes a crash.

The GFLAGS command I asked you to run subsequently causes what's called a "guard page" to be placed either side of a valid heap memory block - a no access area which goes "boom" (triggers a crash) as soon as a writer tries to overrun/underrun a valid heap block. It doesn't catch all types of heap corruption, but it does a great job most of the time.

With guard pages enabled, the code which is attempting to write into a guard page and hence causing a crash looks to be another Explorer component. In other words, MS code within Explorer is seemingly inadvertantly corrupting heap in this instance. The top of the stack:

Child-SP RetAddr Call Site
00000000`410fe980 000007fe`fdac8d22 ole32!CopyFormatEtcDataArray+0x22
00000000`410fe9d0 000007fe`fdaf873e ole32!CreateWrapperClipDataObjectFromFormatsArray+0xe2
00000000`410fea10 000007fe`f9b9e002 ole32!OleGetClipboard+0x9e
00000000`410fea40 000007fe`f9b9df17 EXPLORERFRAME!CShellBrowser::_OnDestroy+0x105
00000000`410fea80 000007fe`f9b9d25e EXPLORERFRAME!CShellBrowser::WndProcBS+0x291

By itself, that might have been a one-off caused by factors I haven't even envisaged. However, others are now uploading identical dumps too (after also running the gflags command), so either you all share a 3rd-party component which is very sophisticated in the way it manages to not only corrupt heap but also make it look like Explorer code is doing it, or there really is a bug in the relevant Explorer code!

I don't have access to Microsoft source, and for reasons difficult to explain succinctly it becomes very impractical for me to try to debug this further over a web forum. However, I'd encourage you to submit these crash dumps to Microsoft. If you can manage to get past the gauntlet of junior engineers and get through to somebody who asks you for a crash dump, it's possible they'll be able to understand what is happening from the perspective of their code.

I could also be entirely wrong. Hence, it would be inadvisable to insist on "a bug". Just ask them to explain why Explorer appears to be the heap corruptor in this instance. They may come up with something which I've missed.

Sorry I wasn't able to propose a resolution, but in some ways you've got the most complex crash of any of the ones being discussed around here recently. Good luck with it, irrespective of what you choose to do.

 

[cvor]

I am getting the same error from time to time but can't duplicate it or figure out what causes it to occur. From what I recall, it also was with ntdll.dll.
Seems to happen and go away randomly. I also got a com surrogate error twice yesterday - both times when closing a picture in the picture viewer. I clicked on the option to let windows resolve and no other windows came up confirming it was fixed but the problem went away.

I downloaded a program that lets you view shell extensions and messed with disabling certain ones but that seems now to now be the issue. Some things I have that may cause problems are CCleaner, winamp, and ffdshow. I have the latest version of everything.

I don't know how to troubleshoot this. I can't even induce a crash. Pretty messed up.

 

[qhimqpb]

I'm having similar experiences to cvor: occasional apparently random explorers crashes and yesterday also a com error of some sort when viewing jpgs. I think this is a Windows bug.