RDR_FILE_SYSTEM - Random BSOD's on Multiple Machines - Windows 8

D

Dynamo

New member
Joined
Jul 21, 2015
Posts
4
Hi,

I've been experiencing a very unusual situation in our office environment. Starting a while back users started to complain about BSOD's, these were occurring at a very sporadic rate but would often happen more than once per day for a specific user. Following these blue screens, they often didn't see any more for days or even weeks. The specific error in the majority of instances was RDR_FILE_SYSTEM (likely caused by mup.sys) which occurred in probably 80-90% of all cases; however, I've also seen ATTEMPTED_WRITE_TO_READONLY_MEMORY and PAGE_FAULT_IN_NONPAGED_AREA errors that also point to mup.sys as being the likely culprit for the crash. There is no consistency in the hardware on the machines that are being affected (we're using Dell's, HP's, Lenovo's and White Box's); the OS's are Windows 8 and 8.1 Pro (both x86 and x64) and they're connected to a Windows SBS 2011 server.

One additional comment: I recently connected a remote office to ours over VPN and as soon as they connected, their machines began having the same issue. My hunch is that this is triggered through communication between the computers and the server, possibly when accessing shared folders located on the server, but I'm not certain, and if it is related, I don't know what set of circumstances are causing this to happen. There are only 3 machines that haven't experienced a BSOD within the network, the SBS server, a Windows 8.1 Pro desktop and 1 Windows 7 Pro laptop (although this machine is infrequently connected to the network).

I've run the Sysnative BSOD Dump + System File Collection App on one of the affected computers and attached the results.

Any assistance you can provide would be appreciated.

Thanks,
Dynamo
 
Code: 
[COLOR=#ff0000]BugCheck 27[/COLOR], {[COLOR=#0000cd]baad0073[/COLOR], ffffd00024a1a5f8, ffffd00024a19e00, [COLOR=#ffa500]fffff80259b5d5ce[/COLOR]}

Probably caused by : mup.sys ( mup!MupFindFileContext+1d )

The baad0073 address corresponds to the RDBSS bugcheck RDBSS_BUG_CHECK_NTEXCEPT, which I assume due to lack of documentation, indicates that the bugcheck was caused by a NT status type error. The RDBSS library is used for debugging purposes.

Code: 
8: kd>[COLOR=#008000] !error 0xc0000005[/COLOR]
Error code: (NTSTATUS) 0xc0000005 (3221225477) - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

The NT status error code indicates that a driver has attempted to access an invalid memory address, this could be due to a bad pool allocation or inappropriate use of pointers.

The fourth parameter provides the address of the instruction which supposedly caused the bugcheck.

I personally think it possibly related to a bad pool allocation which has attempted to use an address which doesn't have the correct access rights.
 
x BlueRobot said:
Thanks, I will look forward to any feedback.
Click to expand...

I've had Driver Verifier running for 2 days now without any BSOD's. I'll keep it running for a few more days to see if anything happens. I made a small change to a network share the day after posting my previous comment and haven't seen a BSOD since. This doesn't necessarily mean anything though as we've had times where over a week goes by without any sign of a blue screen. I'm cautiously optimistic, and if I don't see anymore RDR_FILE_SYSTEM BSOD's in the next week or two, I'll post here with my results.
 
Thanks for the update, I understand what you mean about BSODs, I've seen systems where it won't crash for months but suddenly it would BSOD again.
 
Hi Dynamo,

My organisation is experiencing the exact same issue. We have multiple devices all running windows 8.1 which suddenly started experiencing BSOD's multiple times in a day.

I've taken a look at the crash dumps you uploaded and they are exactly the same as ours.

You mentioned you've made a change which seems to have resolved the issue:
I made a small change to a network share the day after posting my previous comment and haven't seen a BSOD since.
Click to expand...

Could you expand on this and perhaps provide any info on what you've already tried and found?

Cheers
 
Slinky, if you could create another thread, then I could take a deeper look into the dump files if you like? What analysis have you already carried out?
 
Hi BlueRobot,

For the devices we've managed to get a hold of, we've taken off the crash dumps (which are the same on every device), we've checked the device drivers are all up to date and we've run them through a full windows update installing every available patch. It seemed to calm the situation down for about 3 days before it came back with guns blazing.

We suspect it could be a Direct Access related issue but we can't really confirm anything. We are liaising with Microsoft to try and get further analysis of the dumps but we are no further forward.

I have no issue uploading the dumps for you to analyze but I can't run the app mentioned above purely because of security and I think the zip is too large to upload directly to this forum. Would it be ok to upload it to my dropbox account for you to download?

Thanks
 
Slinky said:
Hi Dynamo,

My organisation is experiencing the exact same issue. We have multiple devices all running windows 8.1 which suddenly started experiencing BSOD's multiple times in a day.

I've taken a look at the crash dumps you uploaded and they are exactly the same as ours.

You mentioned you've made a change which seems to have resolved the issue:
I made a small change to a network share the day after posting my previous comment and haven't seen a BSOD since.
Click to expand...

Could you expand on this and perhaps provide any info on what you've already tried and found?

Cheers
Click to expand...

Hi,

It has been nearly two weeks now and we have yet to see a single blue screen for any computer within our network. I am going to assume that the adjustment I made has resolved the issue. The solution was a rather simple one to fix, but one that I stumbled upon by mere coincidence. I was diagnosing something completely different: a user was having trouble connecting to a network share (specifically a share called RedirectedFolders which contains folders for user documents, etc.). When I experienced the same issue with an admin account too, I realized something was wrong. When I checked the "Advanced Sharing" properties for the RedirectedFolders share, I noticed that the value of "x" under "Limit the number of simultaneous users to: x" had been configured to allow too few connections for the number of users accessing this folder within our environment. I simply increased this limit, to more than accommodate our number of users, and the BSOD's have disappeared! Hopefully this continues to be the case over the coming weeks.

I would suggest checking all of your network shares for any limits set, and adjust them accordingly. I hope that you have the same results that we did.

Dynamo
 
Thanks for posting what worked for you. I am sure that this would help the future visitors as well :)


Recently, a similar case came to my attention. Same mup.sys being blamed. On digging further, we found that the organization was running an older version of Lumension Endpoint Security.



-Pranav
 
Hello again,

We've updated Lumension Endpoint security on our servers/clients and the problem continues. The similar case you mentioned is actually the same case posted by a colleague.

We've trawled through a lot of software and drivers making sure everything is up to date. We've followed an action plan suggested by Microsoft to try to capture more data at the time of the crashes and are currently waiting for a response from them. This issue is very strange, just when we think we've found a pattern or a possible solution, it all gets thrown out of the window because another device joins in that doesn't match the pattern. I'll continue to provide updates until we get a definite resolution but for now if anyone has any idea where we can look it would be greatly appreciated.

Thanks
 
Slinky said:
Hello again,

We've updated Lumension Endpoint security on our servers/clients and the problem continues. The similar case you mentioned is actually the same case posted by a colleague.

We've trawled through a lot of software and drivers making sure everything is up to date. We've followed an action plan suggested by Microsoft to try to capture more data at the time of the crashes and are currently waiting for a response from them. This issue is very strange, just when we think we've found a pattern or a possible solution, it all gets thrown out of the window because another device joins in that doesn't match the pattern. I'll continue to provide updates until we get a definite resolution but for now if anyone has any idea where we can look it would be greatly appreciated.

Thanks
Click to expand...
Hi Slinky ^_^,

Any chance you could upload the Dump files?

Let us know how it goes ^_^


-Pranav
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top