Freigeben über

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

  • Artikel

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

  • Anonymous
    November 22, 2012
    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.).

  • Anonymous
    June 09, 2013
    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:   fffff880045ab490 fffff96000ad2500 : 000000000000006a fffff800016d9d32 0000000000000000 00000000000000de : RDPDD!CAutoDrvCheck::CAutoDrvCheck+0x5d fffff880045ab4c0 fffff960000768fa : fffff900c00c2000 00000000000000de fffff900c00bf028 fffffa8000000003 : RDPDD!DrvMovePointerEx+0x28 fffff880045ab4f0 fffff96000076600 : fffffa800d7ed810 000000000000006a fffff900c00c2000 0000000000000000 : win32k!vMovePointer+0x7a fffff880045ab530 fffff9600015b6a3 : fffffa800f3fa5f0 0000000000000000 000000000000006a 0000082200c80000 : win32k!GreMovePointer+0x17c fffff880045ab5c0 fffff9600015a081 : fffff900c0181e04 0000000000c67d7a fffff900c0181ca0 0000000000c67d7a : win32k!xxxMoveEventAbsolute+0x203 fffff880045ab650 fffff96000159ed8 : fffff900c0181ca0 0000006a000000de 0000000000000000 0000000000000286 : win32k!ProcessMouseInput+0x195 fffff880045ab6c0 fffff800016c3651 : 0000000000000100 0000000000000000 0000000000000000 0000000000000001 : win32k!InputApc+0x7c fffff880045ab6f0 fffff800016c681d : fffffa800e0013b0 0000000000000000 fffff96000159e5c 0000000000000000 : nt!KiDeliverApc+0x201 fffff880045ab770 fffff800016d30da : 0000000000000000 0000000000000000 fffffa8000000000 fffff800016c6612 : nt!KiCommitThreadWait+0x3dd fffff880045ab800 fffff960000fa708 : fffff90000000002 fffffa800d1511b0 fffff90000000001 fffff8800000000d : nt!KeWaitForMultipleObjects+0x272 fffff880045abac0 fffff960000fb6d3 : 0000000000000000 fffff900c015f500 fffff960003477c0 0000000000000004 : win32k!xxxMsgWaitForMultipleObjects+0x108 fffff880045abb40 fffff960000b51c4 : fffffa8000000001 fffffa800000000c fffffa800e0013b0 fffff6fc40022a08 : win32k!xxxDesktopThread+0x253 fffff880045abbc0 fffff9600013629a : fffffa8000000001 fffff960003477c0 0000000000000020 0000000000000000 : win32k!xxxCreateSystemThreads+0x64 fffff880045abbf0 fffff800016cfe93 : fffffa800e0013b0 0000000000000004 000007fffffac000 0000000000000000 : win32k!NtUserCallNoParam+0x36 fffff880045abc20 000007fefd2c1eea : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 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