Windows 7: BSOD when connected to Linux Samba share

I just built a new system and installed Windows 7. Everything went fine until I connected to a network share hosted by a Debian Linux box running Samba 3.4.2. I can see the share and it's contents but within 10 minutes Windows 7 will go down with a BSOD complaining about rdbss.sys.

Has anyone else seen this? Any recommendations?

I am running the most recently Windows 7 updates as of this morning (October 19th, 2009).

Easy way to bring down Windows 7.

Pete cant help you yet but can give you info on the problem if you are interested you can go here The Redirected Drive Buffering SubSystem

Ken

RDBSS is what hooks up the SMB redirector to the cache manager component of the OS, and hence to the memory manager.

If you attach some minidumps it may be possible to tell you why the machine is crashing. By far the most likely cause is a 3rd-party "security" driver which is interfering with the network stack in a nasty way - a firewall or anti-virus would be the usual culprits.

I am new to the Windbg program so let me know if more info is appropriate.

I am able to access the share and move files to/from the share. Only after several minutes of being connected do I get the exception. I get the same exception with or without Kaspersky Internet Security installed. If this is an authentication issue, why would it let me read/write files prior to throwing the exception? I believe this to be a bug in the SMB driver in Windows 7.

A picture of the BSOD in attached.

I have a stack trace that shows the frame when the exception occurs:

# ChildEBP RetAddr
00 afc17214 8adc5da1 nt!KeBugCheckEx+0x1e
01 afc1723c 8adbc141 rdbss!RxExceptionFilter+0xba (FPO: [2,0,4])
02 afc17248 8adbadb8 rdbss!RxFsdCommonDispatch+0x7d6 (FPO: [SEH])
03 afc1725c 8adc6ee3 rdbss!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
04 afc17284 82873822 rdbss!_except_handler4+0x8e (FPO: [4,5,4])
05 afc172a8 828737f4 nt!ExecuteHandler2+0x26
06 afc17360 828c8342 nt!ExecuteHandler+0x24
07 afc17778 8284f016 nt!KiDispatchException+0x17c
08 afc177e0 8284efca nt!CommonDispatchException+0x4a (FPO: [0,20,0])
09 afc17800 8add0e23 nt!Kei386EoiHelper+0x192
0a afc1787c 8adbbfb1 rdbss!RxCanonicalizeNameAndObtainNetRoot+0x2cb (FPO: [4,6,0])
0b afc17904 8add6e2b rdbss!RxFsdCommonDispatch+0x646 (FPO: [SEH])
0c afc17934 982cc298 rdbss!RxFsdDispatch+0x1ab (FPO: [2,3,0])
0d afc17950 828474bc mrxsmb!MRxSmbFsdDispatch+0x9a (FPO: [2,0,4])
0e afc17968 8b5e5bb0 nt!IofCallDriver+0x63
0f afc17984 8b5e4b52 mup!MupiCallUncProvider+0x10f (FPO: [1,2,4])
10 afc1799c 8b5e4f5b mup!MupStateMachine+0x9b (FPO: [1,1,0])
11 afc179e8 828474bc mup!MupCreate+0x109 (FPO: [SEH])
12 afc17a00 8af7f20c nt!IofCallDriver+0x63
13 afc17a24 8af928c9 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa (FPO: [3,4,4])


Here is the disassembly at the point the exception occurs:

8add0de1 0300 add eax,dword ptr [eax]
8add0de3 0001 add byte ptr [ecx],al
8add0de5 a100c0dc8a mov eax,dword ptr [rdbss!WPP_GLOBAL_Control (8adcc000)]
8add0dea 3d00c0dc8a cmp eax,offset rdbss!WPP_GLOBAL_Control (8adcc000)
8add0def 7418 je rdbss!RxCanonicalizeNameAndObtainNetRoot+0x2b1 (8add0e09)
8add0df1 f6402004 test byte ptr [eax+20h],4
8add0df5 7412 je rdbss!RxCanonicalizeNameAndObtainNetRoot+0x2b1 (8add0e09)
8add0df7 8d4de8 lea ecx,[ebp-18h]
8add0dfa 51 push ecx
8add0dfb 53 push ebx
8add0dfc 6a15 push 15h
8add0dfe ff7014 push dword ptr [eax+14h]
8add0e01 ff7010 push dword ptr [eax+10h]
8add0e04 e8ee3bffff call rdbss!WPP_SF_Z (8adc49f7)
8add0e09 8b7508 mov esi,dword ptr [ebp+8]
8add0e0c 8b5d14 mov ebx,dword ptr [ebp+14h]
8add0e0f 53 push ebx
8add0e10 33ff xor edi,edi
8add0e12 57 push edi
8add0e13 ff75f4 push dword ptr [ebp-0Ch]
8add0e16 8d45e8 lea eax,[ebp-18h]
8add0e19 50 push eax
8add0e1a ff750c push dword ptr [ebp+0Ch]
8add0e1d 56 push esi
8add0e1e e80a100000 call rdbss!RxFindOrConstructVirtualNetRoot (8add1e2d)
8add0e23 8945fc mov dword ptr [ebp-4],eax
8add0e26 3dd00000c0 cmp eax,0C00000D0h
8add0e2b 751d jne rdbss!RxCanonicalizeNameAndObtainNetRoot+0x2f2 (8add0e4a)
8add0e2d ff763c push dword ptr [esi+3Ch]
8add0e30 e8df580100 call rdbss!RxScavengeVNetRoots (8ade6714)
8add0e35 53 push ebx
8add0e36 57 push edi
8add0e37 ff75f4 push dword ptr [ebp-0Ch]
8add0e3a 8d45e8 lea eax,[ebp-18h]
8add0e3d 50 push eax
8add0e3e ff750c push dword ptr [ebp+0Ch]
8add0e41 56 push esi
8add0e42 e8e60f0000 call rdbss!RxFindOrConstructVirtualNetRoot (8add1e2d)
8add0e47 8945fc mov dword ptr [ebp-4],eax
8add0e4a 53 push ebx
8add0e4b ff1500a0dc8a call dword ptr [rdbss!_imp__FsRtlDoesNameContainWildCards (8adca000)]
8add0e51 84c0 test al,al
8add0e53 743d je rdbss!RxCanonicalizeNameAndObtainNetRoot+0x33a (8add0e92)
8add0e55 a100c0dc8a mov eax,dword ptr [rdbss!WPP_GLOBAL_Control (8adcc000)]
8add0e5a 3d00c0dc8a cmp eax,offset rdbss!WPP_GLOBAL_Control (8adcc000)
8add0e5f 741e je rdbss!RxCanonicalizeNameAndObtainNetRoot+0x327 (8add0e7f)
8add0e61 f6402002 test byte ptr [eax+20h],2
8add0e65 7418 je rdbss!RxCanonicalizeNameAndObtainNetRoot+0x327 (8add0e7f)
8add0e67 53 push ebx
8add0e68 6898a4dc8a push offset rdbss!WPP_ThisDir_CTLGUID_RFSMon+0x40 (8adca498)
8add0e6d 6a16 push 16h

Any thoughts? suggestions on how to proceed from here?

You may be "new to WinDBG" but you clearly have skill and knowledge. Welcome to the forum, and please consider helping yourself to some of the "why the BSODz??!?" questions

Where's the link to authentication? If you're referring to my suggestion that "security" utilities may be interfering, that interference does not necessarily limit itself to the authentication phase.

Entirely possible. It would be a blast to troubleshoot too! You'd want to first verify that it happens on a completely clean install, before getting too deeply embroilled in kernel debugging.

...
8add0e19 50 push eax // push the third function arg
8add0e1a ff750c push dword ptr [ebp+0Ch] // push the second arg
8add0e1d 56 push esi // push the first arg
8add0e1e e80a100000 call rdbss!RxFindOrConstructVirtualNetRoot (8add1e2d)
8add0e23 8945fc mov dword ptr [ebp-4],eax // EBP presumably bad ???
8add0e26 3dd00000c0 cmp eax,0C00000D0h // return = STATUS_REQUEST_NOT_ACCEPTED ?
8add0e2b 751d jne rdbss!RxCanonicalizeNameAndObtainNetRoot+0x2f2 (8add0e4a) // otherwise, branch elsewhere
...

If your analysis of the exception-generating instruction is correct, the return value from rdbss!RxFindOrConstructVirtualNetRoot is being fed into the first space for a "local" in that function - [EBP-4]. Presumably the EBP pointer has gone haywire, though there's not enough info in your output to be sure. (Deterministic) Troubleshooting would involve hooking up the machine to run under a kernel debugger (you'd need another box close by to act as the "controller", setting breakpoints on rdbss!RxFindOrConstructVirtualNetRoot, and stepping through to watch what happens when the return value is being fed into [EBP-4].

I can help, but it's far from a trivial ex3rcise, though I suspect you already know that. You'd really want to nuke+clean_reinstall_from_scratch first, to rule out as many environmental issues as possible.

Otherwise, just let the machine upload the minidump to MS and they'll presumably track it. Their reporting telemetry allows them to work out which issues are likely to be bugs in their code.

Can you upload the minidump? It is very unlikely to contain anything to identify you. They're designed to offer depersonalised triage info.

Same problem here. Just installed Windows 7 Pro 64 bits (fresh install) and as I hook up my samba share and start accessing files I got the same STOP 0x00000027, RDR_FILE_SYSTEM, rdbss.sys BSOD. Sometimes I can be using the share for a couple of hours and sometimes it crashes just as I login. Weird.

Googling it I've found some people who have fixed it updating networking drivers or uninstalling the antivirus. I was using the free MS Security Essentials. I've uninstalled it. Upgraded the networking drivers in my Asus P7P55D. No luck.

Either you and the OP both happen to have the same interfering driver, or there's a bug in the Windows 7 net stack which is exposed by something that samba's doing. Whether samba is following the SMB spec in all respects doesn't even matter. Whatever it's doing shouldn't cause Windows 7 to crash.

You might want to check whether it still happens with a completely "vanilla" install - nothing at all that's not part of the OS disc image. If you manage to repro - bug.

It really happens with the "vanilla" install. Well, this is how actually I installed:

- Vanilla Windows 7 Pro x64 install.
- First boot. I check I have networking (and most drivers installed ok). Just the graphics driver wasn't enough to drive my Dell 30" screen. Download and install. Reboot again.
- Next thing: apply windows updates.
- And finally: hook my network share.

The problem is that the BSOD is not exactly reproducible. I've managed to use a whole morning without glitches (with some access for docs and constantly playing music stored on the samba server). Then you can have a BSOD, the system reboots and as soon as I login again it lasts perhaps 10 or 15 seconds. I've chained as long as 10 reboots this ways (the network share was on "connect on startup" of course). I had to disconnect it in "safe mode" to be able to boot again.

Anyway, do you think the installation can be considered "vanilla" enough? BTW, how I report a bug? The KB from Microsoft seem to be quite read only, I can get to a submit page.

No. Vanilla means absolutely nothing that's not on the Windows disc. It doesn't mean that they won't troubleshoot it, but it does mean you can't be sure at this point whether the problem is "in Windows", or in one of those other drivers or updates.

Either let Windows submit the memory dump to MS, or call up their support and tell them what's going on. They're undoubtedly already getting minidumps submitted along these lines. If it's a bug, it should stand out.

For what it's worth, none of my Windows 7 machines do anything like this, despite accessing multiple samba-mounted shares in various ways. It may be environmental after all.

Thanks for the input. With every crash I've submitted the dump to MS. They probably have several right now (about 30 and counting...).

What worries me is that few people seem to have this problem which is quite severe (BSOD!). And you say any of your Windows 7 have it. It's probably environmental as you say, but then... how can I know? Where to start? I suppose I can only wait to see a fix...