Meta description (152 characters):
Windows Explorer crashed on a Downloads folder, even after a full reset. Here’s the remote troubleshooting process, what worked, and the lessons for IT teams.

Focus keywords:

1. Windows Explorer keeps crashing
2. Explorer crashes when opening Downloads folder
3. exception code 0xc0000374
4. remote IT troubleshooting
5. Windows reset vs repair

---

Introduction

In 30 years of running IT infrastructure, I’ve learned that the problems that look smallest are often the ones that teach the most.

This case study is about a single folder. A user’s Downloads folder on a Windows 11 PC would close File Explorer every time it was opened, and even right-clicking a file inside it triggered the crash. No blue screen, no slow performance, no other symptoms. Everything else on the machine worked normally.

It took us through the standard repair playbook, a remote-only constraint, a crash log full of cryptic codes, a Windows update rollback, a complete system reset, and a final twist: the problem came back the moment the old Downloads folder was restored from backup.

We never identified the exact file responsible. I’m sharing the case anyway, because the process matters more than the ending, and because the “unsolved” part is a lesson in itself.

If you manage IT for a business, or you’ve ever watched File Explorer vanish when you open a folder, this one is for you.

---

The Problem: Explorer Closes the Moment You Open Downloads

The symptoms were simple and consistent:

• Opening the Downloads folder in File Explorer caused the Explorer window to close within moments.
• Right-clicking any file in Downloads closed Explorer immediately.
• Opening any file from that folder had the same result.
• Other parts of the system appeared to work normally.

There was one more constraint that shaped the whole engagement: the PC was not available locally. Everything had to be diagnosed and fixed remotely, which changes what’s safe to try. A wrong move can disconnect the remote session and leave you with a machine you can’t reach.

---

Step 1: Start With the Safe, Common Fixes

When Explorer crashes in one folder, the usual suspects are well known, so we worked through them first, from least to most invasive:

• Restart Explorer and clear its history through Task Manager and Folder Options.
• Reset the folder type. Windows sometimes mis-detects Downloads as a Pictures or Videos folder and tries to generate thumbnails for everything inside. Setting “Optimize this folder for” to General items is a quick test.
• Clear the thumbnail cache, since corrupted thumbnail databases are a classic cause of Explorer crashes.
• Reset saved folder view settings by clearing the Shell Bags registry entries.

None of these changed the behavior. That was already informative: it suggested the problem wasn’t a simple display or cache glitch.

---

Step 2: Rule Out the User Profile

The next question was whether the problem lived in the user’s profile or in the system itself. A new Windows user account is the fastest way to find out. If a brand-new profile works, the old profile’s settings are corrupted and you can migrate the data. If it fails too, the problem is deeper.

In this case, the new profile crashed as well.

That single test removed a whole category of causes. We were no longer looking at user settings, registry entries under one profile, or per-user cache files. We were looking at something system-wide: a shell extension, a system file, a driver, or the folder content itself.

---

Step 3: System File Checks, and a DISM That Wouldn’t Finish

We ran the standard repair tools:

• sfc /scannow finished with no integrity violations. Windows’ protected system files looked healthy.
• DISM /Online /Cleanup-Image /RestoreHealth did not finish. It stalled.

A stalled DISM is common and not always a sign of deeper trouble. It can pause at a percentage for a long time, especially on slower disks, or fail because it can’t reach Windows Update for its repair source. The more reliable approach is to point DISM at a mounted Windows ISO as the source.

At this point, we had to weigh the options against the remote constraint:

• A clean boot (disabling all services and startup items) risks disabling the remote access tool itself.
• chkdsk /f needs a restart and runs before Windows loads, so access is lost until it finishes.
• A repair install or a reset removes or interrupts the remote tool and needs someone at the PC.

This is a good moment to state a principle I repeat to my team: in remote troubleshooting, the order of your steps matters as much as the steps themselves. Prefer tests that are reversible and don’t depend on a restart. Save the risky ones for when someone can be physically present.

---

Step 4: Reading the Crash Log

Guessing had stopped being productive, so we went to the evidence. Windows records every Explorer crash in the Application log, and a single PowerShell command pulls the relevant entries:

powershell

Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000} -MaxEvents 5 |
Where-Object {$_.Message -like '*explorer.exe*'} |
Format-List TimeCreated, Message

The result:

• Faulting application: Explorer.EXE
• Faulting module: ntdll.dll
• Exception code: 0xc0000374
• Fault offset: 0x00000000001181f5

What does 0xc0000374 mean?

Exception code 0xc0000374 is a heap corruption error. Something wrote to memory it shouldn’t have, and Windows detected the damage and terminated the process to protect itself.

Here’s the part many people miss: ntdll.dll is not the culprit. It’s the Windows component that detects the corruption, which is why it shows up as the faulting module. The actual cause is usually something else running inside Explorer’s memory space at the time: a third-party shell extension, a context-menu handler, an icon overlay, a security product’s hook, or a built-in handler parsing a malformed file.

This reframed the whole case:

• It argued against a failing disk, which usually produces file system errors, not a repeatable heap corruption in one folder.
• It made faulty RAM less likely, because a bad memory problem tends to produce random crashes across the system, not a consistent one tied to a single action. (RAM can’t be fully ruled out, but a repeatable crash on one specific action is not its typical signature.)
• It pointed toward software loaded into Explorer, or content Explorer was parsing.

One more observation: the crash signature was identical every time, including the same fault offset. Same crash, same place, same cause.

---

Step 5: The Windows Update Theory

The hotfix history showed three updates installed in the two weeks before we investigated. Heap corruption in Explorer that begins soon after a Windows update is a known pattern, and the Windows build involved was a recent one.

So we tested it the proper way: uninstall the newest update, restart, and test again. A theory only counts once you’ve tried to disprove it.

It didn’t fix the problem. That weakened the update theory considerably, and we stopped spending time on the other two updates.

I want to highlight this because it’s a common trap. When a problem appears around the time of an update, the update gets blamed. Sometimes that’s right. Often it’s coincidence. The only way to know is to test, and to be willing to move on when the test fails.

---

Step 6: The Decision to Reset

By now, the evidence read like this:

• New profile: still crashes
• SFC: clean
• DISM: wouldn’t complete
• Cause: heap corruption, probably third-party code or a parsed file
• Update rollback: no change
• Downloads folder in particular: crashes on open

The client wanted to reset the PC. I was honest about the trade-off: a reset fixes software causes (corrupted system files, a bad extension, a broken driver), but it wouldn’t fix a failing disk, faulty RAM, or a problem that lives inside the data you restore afterwards. It was a reasonable bet, not a guarantee.

Since the PC would be wiped, we planned it carefully:

• A full backup of all user data to a drive that was not the one being reset
• Verification that files opened correctly from the backup
• Business data covered: email archives, documents, accounting and tax files
• A list of installed programs and licenses
• Someone on site for the reset, since it restarts several times and removes the remote tool

The reset was done with the Remove everything option, which gives the cleanest possible test.

---

Step 7: The Clean System Test

After the reset, the first test was the most important one: before restoring anything, open the Downloads folder and right-click a file.

It worked perfectly.

This was the key result of the whole engagement. A clean Windows install with a clean Downloads folder was stable. That told us:

• The hardware was fine. The RAM test we’d been prepared to run was no longer necessary.
• The cause was something on the old installation, whether software or data.

---

Step 8: The Twist, the Old Downloads Folder Brings It Back

The system was stable, and then the old Downloads folder from the backup was opened.

The crash returned.

This was the turning point. A freshly installed, fully updated Windows 11 machine, with no third-party software yet, crashed on that folder, and the crash signature was identical: same exception code, same fault offset, same build.

That ruled out the old installation, the old profile, old drivers and old extensions as the cause. Something inside the folder itself was triggering the crash.

---

Step 9: Bisecting a Folder Without Opening It

If opening a folder crashes Explorer, you can’t use Explorer to investigate the folder. So everything moved to PowerShell:

powershell

# Group files by extension without opening the folder in Explorer
Get-ChildItem "D:\Backup\Downloads" -Recurse -File |
Group-Object Extension | Sort-Object Count -Descending |
Select-Object Count, Name

# Look for the classic suspects: zero-byte files, very long names, shortcuts
Get-ChildItem "D:\Backup\Downloads" -Recurse -File |
Where-Object { $_.Length -eq 0 -or $_.Name.Length -gt 120 } |
Select-Object FullName, Length

Then the classic approach: bisection. Copy the files in batches into a fresh test folder, open it in Explorer, and see whether it survives. When a batch crashes, split that batch in half and test each half. Keep halving until one file is left.

In practice, the client’s team took a more pragmatic route. They deleted the problem files from the working Downloads folder, then copied back only the files the user actually needed, in batches, testing as they went. Every batch they copied was stable.

---

The Outcome: Solved in Practice, Unsolved in Theory

Here’s the honest ending: we never identified the specific file.

The user’s important files were restored and everything worked. The rest stayed in the backup, which was set aside and not opened again on that machine. The system was stable, the user was productive, and the remaining files were mostly years of accumulated download clutter.

Was that a failure? I’d argue it was the correct engineering call. The cost of finding one corrupt file among thousands of old downloads was higher than the value of finding it. We got to a stable, verified outcome and made sure the risk stayed contained.

---

“Does This Mean a File Was Running Code?”

This was the natural question, and it deserves a straight answer.

Most likely, no. Opening a folder makes Explorer read each file’s metadata: icon, thumbnail, properties, preview. It does this using built-in handlers. A corrupted or oddly structured file (a damaged PDF, image, video, .lnk shortcut or archive) can cause one of those handlers to write to memory incorrectly. That produces exactly the heap corruption we saw. Nothing is “running.” Windows’ own parser is mishandling bad data. Years of half-finished and interrupted downloads make this far more likely than anything sinister.

But it can’t be fully ruled out. Malformed files can be deliberately crafted to exploit parser bugs, and shell-parsing flaws have been used in real attacks. That’s why we recommended scanning with a second engine.

The client’s endpoint security (Kaspersky Cloud) found nothing. That’s reassuring but not conclusive: antivirus catches known malware and behaviors, and a merely corrupted file won’t be flagged at all. A second opinion from a different engine, such as Microsoft Defender’s offline scan, is cheap insurance, and so is scanning the backup drive before connecting it elsewhere.

The balanced conclusion: most likely a corrupted file, possibly something crafted, definitely something to quarantine. The contained approach covers both.

---

Lessons for IT Teams and Business Owners

1. Isolate scope before you fix anything.
“Explorer crashes” is vague. “Explorer crashes only in Downloads, even on a new profile” is a diagnosis in the making. Every test that narrows the scope saves hours.

2. Read the crash log early.
We lost time on generic fixes before pulling the actual error. Exception codes are cryptic, but they separate categories of cause quickly. 0xc0000374 told us “memory corruption by something loaded or parsed,” which is very different from “disk failure.”

3. Remember what the faulting module tells you, and what it doesn’t.
ntdll.dll appeared in the log, but it only detected the problem. Don’t uninstall Windows components because a log names them.

4. Remote work needs a different playbook.
Anything that restarts the machine, disables services, or removes the remote tool is a one-way door unless someone can be on site. Plan the order of steps around that.

5. Test theories you’re tempted to believe.
The update theory was plausible and wrong. We tested it, discarded it, and moved on.

6. Treat a clean-install test as a diagnostic, not just a fix.
The reset resolved the system side and exposed the data side. If we had restored everything at once, we’d have blamed the reinstall and learned nothing. Restoring in stages is what revealed the real trigger.

7. Don’t restore everything blindly.
Backups preserve problems along with data. Restore user data in stages, test between stages, and leave behind what you can’t verify.

8. Know when to stop.
Finding the root cause is valuable. Finding it at any cost isn’t. Define a stopping point: a stable system, verified data, and contained risk.

---

A Practical Checklist for Your Own PCs

• Don’t let Downloads become a junkyard. Review and clear it regularly. Old installers and half-finished downloads are the most likely carriers of both clutter and corruption.
• Keep backups on storage that isn’t permanently attached, and scan them before restoring.
• Standardize on a tested remote access tool installed as an unattended service, so a restart doesn’t strand you.
• Keep endpoint security current, and use a second-opinion scanner occasionally for suspicious files.
• Keep a short list of safe PowerShell diagnostics ready for remote sessions, including the crash-log command above.
• Document the process, not just the fix. The next occurrence will be faster because of it.

---

Frequently Asked Questions

Why does Explorer crash when I open a folder or right-click a file?
Usually because something loaded into Explorer is misbehaving: a third-party context-menu extension, an icon overlay, a security product hook, or a built-in handler parsing a damaged file.

What does exception code 0xc0000374 mean?
It indicates heap corruption: a process wrote to memory it shouldn’t have. The module named in the log (often ntdll.dll) is where the damage was detected, not necessarily the cause.

Will resetting Windows fix Explorer crashes?
It fixes software causes such as corrupted system files or a bad extension. It won’t fix hardware causes, and it won’t help if the trigger is in the data you restore afterwards, which is what happened here.

Can a corrupted file crash Explorer?
Yes. Explorer reads file metadata just by displaying a folder, and a malformed file can make a handler mishandle memory.

Can a file crash Explorer without being malware?
Yes, and it’s the more common explanation. But a crafted file can’t be ruled out, so scan with more than one engine.

Is it safe to troubleshoot this remotely?
Yes, if you stick to reversible steps and avoid anything that disables or removes your remote tool unless someone can be on site.