Windows Explorer has stopped responding

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

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.

sphericalpuma said:

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?

sphericalpuma said:

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.)

sphericalpuma said:

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.

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.

H2SO4 said:

sphericalpuma said:

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

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