Tech Community Live: Windows edition
Jun 05 2024, 07:30 AM - 11:30 AM (PDT)
Microsoft Tech Community

RunTimeBroker.exe crashing - many machines impacted and crashing taking gigs of space

Copper Contributor

We are seeing Runtimebroker.exe crashing on 20-30+ machines per day and the crashes are taking up gigs of disk space.  Is anyone at Microsoft aware of a fix for this?  We opened a support ticket and even provided the actual crash DMP files to Microsoft, yet support wasn't able to help.  After searching for info about this issue it appears many other people have complained about RunTimeBroker.exe crashing; I tried some suggestions from others about fixing it with various powershell commands/etc but nothing worked.

 

Example crash logs below:

 

Faulting application name: RuntimeBroker.exe, version: 10.0.19041.746, time stamp: 0x5b78739c
Faulting module name: ntdll.dll, version: 10.0.19041.2130, time stamp: 0xb5ced1c6
Exception code: 0xc0000374
Fault offset: 0x00000000000ff6a9
Faulting process id: 0x1af4
Faulting application start time: 0x01d93258aa83942f
Faulting application path: C:\Windows\System32\RuntimeBroker.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 72d103e3-4d4b-42d7-af72-b7dbd64d0801
Faulting package full name: Microsoft.Windows.Search_1.14.7.19041_neutral_neutral_cw5n1h2txyewy
Faulting package-relative application ID: runtimebroker07f4358a809ac99a64a67c1

 

 

Faulting application name: RuntimeBroker.exe, version: 10.0.19041.746, time stamp: 0x5b78739c
Faulting module name: ntdll.dll, version: 10.0.19041.2130, time stamp: 0xb5ced1c6
Exception code: 0xc0000374
Fault offset: 0x00000000000ff6a9
Faulting process id: 0x1af4
Faulting application start time: 0x01d93258aa83942f
Faulting application path: C:\Windows\System32\RuntimeBroker.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 72d103e3-4d4b-42d7-af72-b7dbd64d0801
Faulting package full name: Microsoft.Windows.Search_1.14.7.19041_neutral_neutral_cw5n1h2txyewy
Faulting package-relative application ID: runtimebroker07f4358a809ac99a64a67c1

 

Has anyone else seen this?  Any suggestions?

 

Thanks

 

5 Replies

Hi @ArcticMyst 

I found this article, obviously not about this application , but maybe it will show the direction , which will help to fix it:

ntdll.dll application error (0xc0000374) - Microsoft Q&A

Thanks for reply, already tried but no luck

I would like to mention that every single machine with the crashing has runtimebroker.exe 10.0.19041.746. And also we have hundreds of machines with this same version of runtimebroker.exe which are *not* crashing. Can someone working at Microsoft please confirm what the latest version of runtimebroker.exe is? Is this a known issue? Can someone help escalate our ticket? We gave the actual dump files and query data from defender of the crashes, but despite the specific/actionable data we gave, the support is asking us to provide non-relavant/useless information when the case just needs be be escalated to someone who is an actual software developer

@ArcticMyst 

I understand, but in MTC - you can get a response from other users, (who are not Microsoft employees)

Try asking a question, a new question in a space I shared earlier.

But, it is worth analyzing the configuration of machines that do not have failures, and then perform a check.

No one will speed up the work of Microsoft support - these are separate spaces

Best regards

 

"Faulting package full name: Microsoft.Windows.Search_1.14.7.19041"

I re-read this thread and it seems that the problem is due to the incorrect implementation of Windows updates (KB installation is missing) or has been corrupted

 

 

Hi ArcticMyst,

What exactly takes a lot of space ?
The dump files of the crashing processes.... when processes crash they make .DMP files via werfault.exe which take up space and these can take gigs of space... we have the logs of it happening because run queries for this in Defender/Sentinel.. there should be Zero Crashing especially from Microsoft processes. Why doesn't Microsoft automatically collect diagnostics for stuff like this and proactively fix the code? If you take a dump, clean it up... not our mess to be figuring out the problem with the crashing code.