Freigeben über

[RESOLVED] Win2008R2 RTM/SP1: STOP 0x3B in rdbss!RxFsdCommonDispatch+ad7

  • Artikel

Status: Resolved

Update 120531: Yes! The Private is approved. We are releasing the hotfix in the July Release Cycle, under KB2719704.

Update 120510: We are now testing a private at several customers... fingers crossed this fixes this long-runner! :D

Update 120417: Still ongoing, we are now awaiting verifier-enabled dumps for the crash. If you have this issue too, please enable "verifier /volatile /flags 0x9 /adddriver rdpdr.sys rdbss.sys" and send me the resulting dump.

Update 120217: Yesterday I received an instrumented rdpdr.sys to implement on affected machines. To be able to obtain this and help us find the root cause of this, please create a support case and contact me.

Update 120120: Recently I've filed an RFC on this issue, to get Engineering assistance on resolving this. I expect some update later next week.

Update 111115: Two more customers reported this. Since we know that when we enable full Redirector (Rdr) tracing the problem goes away, I figured out some "light-weight" Rdr tracing. Also, we enabled RdpDr tracing since we suspect a race condition between Rdr and RdpDr. If you run into this problem please enable the tracing and contact me:

tracelog.exe -start RdrMup -guid #fc4b0d39-e8be-4a83-a32f-c0c7c4f61ee4 -b 256 -min 256 -max 256 -f %systemroot%\system32\LogFiles\mup.etl -flag 0x0f00000f -level 5
logman create trace RdpDr -ow -o %SYSTEMROOT%\system32\LogFiles\rdpdr.etl -p {73BFB78F-12B5-4738-A66C-A77BCD55FA12} 0x1 0xf -nb 256 256 -bs 256 -mode 0x2 -f bincirc -max 100 -ets

Note: Tracelog comes with the WDK, LogMan is included in the OS.

Update 111109: The first customer hitting this came back: they had the problem again... awaiting further information now.

Update 111108: This issue went silent for some time... Two customers that encountered this stopped having the problem after implementing KBs 2579362 & 2521220. Today, a customer running SP1 contacted me, also encountering this issue.

Update 110808: Still no crash with the instrumentation and tracing running... customer notified me that their environment is still not running at full load because of the holiday season. Now we wait...

Recently, this case came to my attention, although it's been going on for quite some time. Perhaps there are more people out there who have servers experiencing this issue... :) If so, please let me know!

The stack of this problem shows:

2: kd> knL
 # Child-SP RetAddr Call Site
00 fffff880`03b30398 fffff800`018ccca9 nt!KeBugCheckEx
01 fffff880`03b303a0 fffff800`018cc5fc nt!KiBugCheckDispatch+0x69
02 fffff880`03b304e0 fffff800`018f340d nt!KiSystemServiceHandler+0x7c
03 fffff880`03b30520 fffff800`018faa90 nt!RtlpExecuteHandlerForException+0xd
04 fffff880`03b30550 fffff800`019079ef nt!RtlDispatchException+0x410
05 fffff880`03b30c30 fffff800`018ccd82 nt!KiDispatchException+0x16f
06 fffff880`03b312c0 fffff800`018cabb4 nt!KiExceptionDispatch+0xc2
07 fffff880`03b314a0 fffff880`02e172e0 nt!KiBreakpointTrap+0xf4
08 fffff880`03b31630 fffff880`02e35b74 rdbss!RxFsdCommonDispatch+0xad8
09 fffff880`03b31720 fffff880`04b8acd7 rdbss!RxFsdDispatch+0x224
0a fffff880`03b31790 fffff880`018b8271 rdpdr!DrPeekDispatch+0x31f
0b fffff880`03b317e0 fffff880`018b6138 mup!MupiCallUncProvider+0x161
0c fffff880`03b31850 fffff880`018b6b0d mup!MupStateMachine+0x128
0d fffff880`03b318a0 fffff880`013006af mup!MupFsdIrpPassThrough+0x12d
0e fffff880`03b318f0 fffff880`018f794d fltmgr!FltpDispatch+0x9f
0f fffff880`03b31950 fffff880`013006af mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x105
10 fffff880`03b319b0 fffff800`01be8707 fltmgr!FltpDispatch+0x9f
11 fffff880`03b31a10 fffff800`01be8f66 nt!IopXxxControlFile+0x607
12 fffff880`03b31b40 fffff800`018cc993 nt!NtDeviceIoControlFile+0x56
13 fffff880`03b31bb0 00000000`7721f72a nt!KiSystemServiceCopyEnd+0x13

We hit a Debug Breakpoint (0x80000003) because of an APC issue. Currently, we are working on instrumentation that will tell us where the APC problem is located. As soon as we know that, we can start thinking of a fix.

To be continued...

Comments

  • Anonymous
    January 01, 2003
    @George: sorry for the delay! :$ This is not an IO-issue afaik, it happens with redirecting folders. However, it does appear that the issue is load-related. Can you please enable "verifier /flags 0x9 /driver rdpdr.sys rdbss.sys" and create a case with us?

  • Anonymous
    August 10, 2011
    Same exact stack here: Child-SP          RetAddr           Call Site fffff880326df458 fffff80005ac7ca9 nt!KeBugCheckEx fffff880326df460 fffff80005ac75fc nt!KiBugCheckDispatch+0x69 fffff880326df5a0 fffff80005aee40d nt!KiSystemServiceHandler+0x7c fffff880326df5e0 fffff80005af5a90 nt!RtlpExecuteHandlerForException+0xd fffff880326df610 fffff80005b029ef nt!RtlDispatchException+0x410 fffff880326dfcf0 fffff80005ac7d82 nt!KiDispatchException+0x16f fffff880326e0380 fffff80005ac5bb4 nt!KiExceptionDispatch+0xc2 fffff880326e0560 fffff88003797d08 nt!KiBreakpointTrap+0xf4 fffff880326e06f0 fffff880037b5614 rdbss!RxFsdCommonDispatch+0xad8 fffff880326e07e0 fffff8800618ecd7 rdbss!RxFsdDispatch+0x224 fffff880326e0850 fffff880017d7271 rdpdr!DrPeekDispatch+0x31f fffff880326e08a0 fffff880017d5138 mup!MupiCallUncProvider+0x161 fffff880326e0910 fffff880017d5b0d mup!MupStateMachine+0x128 fffff880326e0960 fffff880013a56af mup!MupFsdIrpPassThrough+0x12d fffff880326e09b0 fffff80005de1547 fltmgr!FltpDispatch+0x9f fffff880326e0a10 fffff80005de1da6 nt!IopXxxControlFile+0x607 fffff880326e0b40 fffff80005ac7993 nt!NtDeviceIoControlFile+0x56 fffff880326e0bb0 000000007717f72a nt!KiSystemServiceCopyEnd+0x13 This seems to happen for us when Win2k8R2 terminals servers are under a load of around 200 users.  The server sometimes bluescreens, sometimes the UmRDPService stops responding.  

  • Anonymous
    March 09, 2012
    Same here but only about 10 users Is this an IO issue? We are also getting large numbers of 7011s in the system log.

  • Anonymous
    May 24, 2012
    I am getting the same issue and I am suspecting that this KB can fix it support.microsoft.com/.../2525246. Dumps: RetAddr           : Args to Child                                                           : Call Site fffff8000207eb29 : 000000000000003b 0000000080000003 fffff88002e17d07 fffff880076c4ca0 : nt!KeBugCheckEx fffff8000207e47c : fffff880076c5438 fffff880076c4ca0 0000000000000000 fffff800020adb50 : nt!KiBugCheckDispatch+0x69 fffff800020a52dd : fffff800022a2bd0 fffff800021c8a70 fffff8000200f000 fffff880076c5438 : nt!KiSystemServiceHandler+0x7c fffff800020ac950 : fffff800021cf198 fffff880076c45d8 fffff880076c5438 fffff8000200f000 : nt!RtlpExecuteHandlerForException+0xd fffff800020b98cf : fffff880076c5438 fffff880076c4ca0 fffff88000000000 01cd3a11dccb7d62 : nt!RtlDispatchException+0x410 fffff8000207ec02 : fffff880076c5438 01cd3a11efbea7ac fffff880076c54e0 fffff78000000014 : nt!KiDispatchException+0x16f fffff8000207ca34 : 00000000000007ff 0000000000000650 fffffa8034b97a60 fffff880076c5560 : nt!KiExceptionDispatch+0xc2 fffff88002e17d08 : 0000000000000000 fffff880076c56b0 0000000000000000 0000000000000000 : nt!KiBreakpointTrap+0xf4 fffff88002e35614 : fffffa809c011570 000000000000000e 000000006349754d fffff800021b34d3 : rdbss!RxFsdCommonDispatch+0xad8 fffff88008bcbcd7 : fffffa809c011570 fffffa806349754d fffffa8021b0d620 0000000000000000 : rdbss!RxFsdDispatch+0x224 fffff880019d5271 : fffffa801eb913d0 fffffa8023651cc0 fffffa809c011570 0000000000000000 : rdpdr!DrPeekDispatch+0x31f fffff880019d3138 : fffff8a0001878c0 fffffa8023651cc0 0000000000000001 0000000000000000 : mup!MupiCallUncProvider+0x161 fffff880019d3b0d : fffffa809c011570 fffff880019d1110 fffffa8021b17de0 0000000000000000 : mup!MupStateMachine+0x128 fffff880014de6af : fffffa801eb913d0 fffffa8023651cc0 fffff880076c5c00 fffffa809c011570 : mup!MupFsdIrpPassThrough+0x12d fffff8800158b81a : fffffa801eb90010 0000000000000003 fffffa801eb90010 fffff880076c5c00 : fltmgr!FltpDispatch+0x9f fffff80002397597 : fffffa8021b17de0 fffff880076c5ca0 fffffa8021b17de0 fffffa809c011570 : mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x13a fffff80002397df6 : 0000000000000001 0000000000000000 0000000000000000 0000000000000000 : nt!IopXxxControlFile+0x607 fffff8000207e813 : fffffa8020bfcb60 fffff880076c5ca0 0000000000000000 fffff80002392200 : nt!NtDeviceIoControlFile+0x56 0000000076e6f72a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x76e6f72a

  • Anonymous
    August 05, 2014
    Still seeing this on 2008R2SP1 RDS servers. Yust had two crashes in last two days with 3B and D5 stop errors in rdbss.sys. Was this fix included in SP1? Silence on thread and in comments suggests that original problem probably have been fixed. Haven't applied HotFix on the affected RDS server yet.

  • Anonymous
    August 05, 2014
    The comment has been removed