Debugging In Progress...

This blog is intended to provide information on debug issues encountered in Microsoft Support, such as STOP errors or hanging servers.

[UNRESOLVED] Win2008R2 SP1: STOP 0x3B in RDPDD!CAutoDrvCheck::CAutoDrvCheck+5d

[UNRESOLVED] Win2008R2 SP1: STOP 0x3B in RDPDD!CAutoDrvCheck::CAutoDrvCheck+5d

  • Comments 2
  • Likes

Status: Unresolved, workaround provided.

Update 121122: Closing the loop on this one... we have also seen a slight variation on this with "RDPDD!CAutoDrvCheck::CAutoDrvCheck+0x5e" instead of offset 0x5d as shown below. A hotfix request for this was rejected, and also on Windows Server 2012 this problem can occur. It only happens when having two or more CPUs. The workaround thus is to limit the machine to 1 CPU. If you encounter this problem and for some reason you feel the workaround is unacceptable, I am more than happy to work with you to try and get this fixed (again). In that case, please open a support case and let me know!

Late last night I had a look at an interesting STOP 0x3B, occurring in rdpdd.dll with the following stack:

00 fffff880`08359490 fffff960`00ac2500 RDPDD!CAutoDrvCheck::CAutoDrvCheck+0x5d
01 fffff880`083594c0 fffff960`00056952 RDPDD!DrvMovePointerEx+0x28
02 fffff880`083594f0 fffff960`0005665c win32k!vMovePointer+0x7a
03 fffff880`08359530 fffff960`00139987 win32k!GreMovePointer+0x17c
04 fffff880`083595c0 fffff960`00138365 win32k!xxxMoveEventAbsolute+0x203
05 fffff880`08359650 fffff960`001381bc win32k!ProcessMouseInput+0x195
06 fffff880`083596c0 fffff800`0148a3b1 win32k!InputApc+0x7c
07 fffff880`083596f0 fffff800`0149c19d nt!KiDeliverApc+0x201
08 fffff880`08359770 fffff800`0149b4aa nt!KiCommitThreadWait+0x3dd
09 fffff880`08359800 fffff960`000d8c48 nt!KeWaitForMultipleObjects+0x272
0a fffff880`08359ac0 fffff960`000d9c14 win32k!xxxMsgWaitForMultipleObjects+0x108
0b fffff880`08359b40 fffff960`000947b8 win32k!xxxDesktopThread+0x254
0c fffff880`08359bc0 fffff960`0011469a win32k!xxxCreateSystemThreads+0x64
0d fffff880`08359bf0 fffff800`01495f93 win32k!NtUserCallNoParam+0x36
0e fffff880`08359c20 000007fe`fce21eea nt!KiSystemServiceCopyEnd+0x13

Failure bucket is X64_0x3B_RDPDD!CAutoDrvCheck::CAutoDrvCheck+5d. This looks to be a concurrency issue, but I need to dig in a bit more into this. Keep watching this space! :)

Comments
  • I use Windows 2008R2 64-bit, and I see more-or-less the same problems. I can provide some more technical details.

    The problem reproduces when creating and destroying sessions rapidly. MSTSC That is, create several sessions, and then destroy them and create new ones rapidly. ActiveX control may be used for this.

    Eventually the OS starts to "misbehave" regarding the display driver (RDPDD). This may include the following:

       Call to DrvEnablePDEV, whereas the same PDEV is already enabled (i.e. DrvDisablePDEV was not called).

       Call to DrvDisableDriver, whereas the driver still manages a PDEV (i.e. DrvDisablePDEV was not called).

       Call to DrvDisablePDEV, whereas there are still device bitmap managed (i.e. they were not destroyed by DrvDeleteDeviceBitmap).

    It seems like the OS eventually "leaks" the allocated display driver resources. This in turn causes problems in RDPDD (such as page fault and etc.).

  • I do have more or less this issue, with a SINGLE cpu.

    FOLLOWUP_IP:

    RDPDD!CAutoDrvCheck::CAutoDrvCheck+5d

    BUCKET_ID:  X64_0x3B_RDPDD!CAutoDrvCheck::CAutoDrvCheck+5d

    STACK_TEXT:  

    fffff880`045ab490 fffff960`00ad2500 : 00000000`0000006a fffff800`016d9d32 00000000`00000000 00000000`000000de : RDPDD!CAutoDrvCheck::CAutoDrvCheck+0x5d

    fffff880`045ab4c0 fffff960`000768fa : fffff900`c00c2000 00000000`000000de fffff900`c00bf028 fffffa80`00000003 : RDPDD!DrvMovePointerEx+0x28

    fffff880`045ab4f0 fffff960`00076600 : fffffa80`0d7ed810 00000000`0000006a fffff900`c00c2000 00000000`00000000 : win32k!vMovePointer+0x7a

    fffff880`045ab530 fffff960`0015b6a3 : fffffa80`0f3fa5f0 00000000`00000000 00000000`0000006a 00000822`00c80000 : win32k!GreMovePointer+0x17c

    fffff880`045ab5c0 fffff960`0015a081 : fffff900`c0181e04 00000000`00c67d7a fffff900`c0181ca0 00000000`00c67d7a : win32k!xxxMoveEventAbsolute+0x203

    fffff880`045ab650 fffff960`00159ed8 : fffff900`c0181ca0 0000006a`000000de 00000000`00000000 00000000`00000286 : win32k!ProcessMouseInput+0x195

    fffff880`045ab6c0 fffff800`016c3651 : 00000000`00000100 00000000`00000000 00000000`00000000 00000000`00000001 : win32k!InputApc+0x7c

    fffff880`045ab6f0 fffff800`016c681d : fffffa80`0e0013b0 00000000`00000000 fffff960`00159e5c 00000000`00000000 : nt!KiDeliverApc+0x201

    fffff880`045ab770 fffff800`016d30da : 00000000`00000000 00000000`00000000 fffffa80`00000000 fffff800`016c6612 : nt!KiCommitThreadWait+0x3dd

    fffff880`045ab800 fffff960`000fa708 : fffff900`00000002 fffffa80`0d1511b0 fffff900`00000001 fffff880`0000000d : nt!KeWaitForMultipleObjects+0x272

    fffff880`045abac0 fffff960`000fb6d3 : 00000000`00000000 fffff900`c015f500 fffff960`003477c0 00000000`00000004 : win32k!xxxMsgWaitForMultipleObjects+0x108

    fffff880`045abb40 fffff960`000b51c4 : fffffa80`00000001 fffffa80`0000000c fffffa80`0e0013b0 fffff6fc`40022a08 : win32k!xxxDesktopThread+0x253

    fffff880`045abbc0 fffff960`0013629a : fffffa80`00000001 fffff960`003477c0 00000000`00000020 00000000`00000000 : win32k!xxxCreateSystemThreads+0x64

    fffff880`045abbf0 fffff800`016cfe93 : fffffa80`0e0013b0 00000000`00000004 000007ff`fffac000 00000000`00000000 : win32k!NtUserCallNoParam+0x36

    fffff880`045abc20 000007fe`fd2c1eea : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13

    2 years ago when we opened up a paid call with support we got told that single CPU would fix the issue. it NEVER did.

    François

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment