Mrrrr's Forum (VIEW ONLY)
Un forum care ofera solutii pentru unele probleme legate in general de PC. Pe langa solutii, aici puteti gasi si alte lucruri interesante // A forum that offers solutions to some PC related issues. Besides these, here you can find more interesting stuff.
|
Lista Forumurilor Pe Tematici
|
Mrrrr's Forum (VIEW ONLY) | Reguli | Inregistrare | Login
POZE MRRRR'S FORUM (VIEW ONLY)
Nu sunteti logat.
|
Nou pe simpatie:
Alexandra21 Profile
 | Femeie
24 ani
Calarasi
cauta Barbat
24 - 53 ani |
|
Mrrrr
AdMiN
 Inregistrat: acum 19 ani
Postari: 2386
|
|
Several explorer.exe crashes happened in the past few months with ntdll.dll as faulting module.
Got into Gemini to describe what I was doing yesterday when the crash happened. It hadn't happened for a while.
What I was doing at the moment of the crash was open a folder (by double click) while recycle bin was being emptied.
I figured it must have been a third-party extension causing the issues. I had Windhawk installed at one point and although I uninstalled it a while back, I though it might have left some handlers that were crashing my explorer.
To my understanding ntdll.dll is a core API layer of Windows and it is very unlikely to cause the crashes itself.
Ran sfc /scannow just to make sure, but it found no issues.
I downloaded NirSoft's ShellExView and hid the Microsoft extensions from Options - Hide All Microsoft extensions, then disabled some of them although all were programs I have been using for years.
Gemini suggested I use an app like NirSoft's AppCrashView to check the secondary modules, the ones under ntdll.dll most likely causing the crashes.
Unfortunately AppCrashView did not see any explorer.exe crashes. I saw other crashes, but not those.
Gemini's answer to that was:
| AppCrashView gets its data strictly from Windows Error Reporting (WER) .wer files. When explorer.exe crashes, Windows frequently handles the restart automatically without completing the full WER reporting cycle to local disk. Because explorer.exe is the critical shell process, Windows prioritizes keeping the UI running over archiving the crash stack, so AppCrashView comes up empty for it. |
Gemini had another suggestion - to enable Local Dumps so that the next time it happens I get a full dmp file explaining what happened.
- opened command prompt as admin (start - run - cmd - ctrl+shift+enter)
- ran each of the following commands:
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpCount /t REG_DWORD /d 5 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2 /f
md C:\CrashDumps |
All the above happened yesterday evening. Today while I was emptying recycle bin I double clicked a folder on one of my drives and I had my crash and explorer restart.
A 1.2 GB .dmp file was created in C:\CrashDumps.
From Microsoft Store, I installed WinDbg and opened the .dmp file in WinDbg.
Ran the following command first to set Microsoft symbol path (dunno if it was done automatically but preferred not to risk it not being already enabled):
Then I ran the following command to get a summary of the fault:
After it processed, I provided the following info to Gemini - MODULE_NAME / IMAGE_NAME, FAILURE_BUCKET_ID, STACK_TEXT
MODULE_NAME: shell32
IMAGE_NAME: shell32.dll
FAILURE_BUCKET_ID: HEAP_CORRUPTION_ACTIONABLE_BlockNotBusy_DOUBLE_FREE_c0000374_shell32.dll!CRecycleBinBase::Release
STACK_TEXT: 00000000`00000000 00000000`00000000 shell32!CRecycleBinBase::Release+0x0 |
FAILURE_BUCKET_ID tells what happened. Gemini explanations:
- DOUBLE_FREE (0xc0000374): A double-free is a heap corruption bug. It occurs when a piece of software tries to free (release) the exact same block of memory twice. The second time it tries to release it, ntdll.dll step in to guard heap integrity, sees the memory block is no longer marked as busy, panics to prevent memory exploitation, and instantly crashes explorer.exe.
- shell32.dll!CRecycleBinBase::Release: This points directly to the native Windows Recycle Bin shell handler!
When you empty the Recycle Bin, shell32.dll creates a handle (CRecycleBinBase) to track the deletion state across all drives.
At the exact same time, when you double-clicked to open a folder on the drive, Explorer spawned a new thread to check folder attributes and update the UI navigation bar—which queries the drive state (including the Recycle Bin state on that partition).
Because both threads were querying and releasing CRecycleBinBase pointers simultaneously during the deletion process, a thread race condition occurred where both threads tried to free the same Recycle Bin object in memory at once.
Since the fault happened natively inside shell32.dll under c0000374 (Heap Corruption), this isn't caused by a corrupted third-party extension - it's a concurrency timing bug in the Windows Shell itself when handling multi-threaded I/O state changes. |
1. Clear Corrupted Recycle Bin Metadata
Sometimes the hidden $Recycle.Bin folder on a drive accumulates corrupt pointer metadata or orphaned system handles, making CRecycleBinBase crash during concurrency. Resetting it purges those bad handles.
Ran the following commands in cmd opened as admin:
rd /s /q C:\$Recycle.Bin
rd /s /q D:\$Recycle.Bin
rd /s /q E:\$Recycle.Bin
rd /s /q F:\$Recycle.Bin |
2. Disabling Crash Dumps
Since the faulting dll was found and fixes were applied, I wanted to disable the crash dumps.
I deleted the C:\CrashDumps folder.
From cmd as admin I ran the following command to remove the registry LocalDumps rule:
| reg delete "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /f |
_______________________________________
|
|
| pus acum 3 saptamani |
|