Windwos 10 RS3 UCM Bug

Hi, I’m upgrade to Windows 10 x64 RS3 and got BSOD from one of my old driver. Analyzing the memory dump point out that driver UCMCx.sys caused the BSOD when create UCM Connecter. The UCM Initialization was follow guideline on MSDN here: https://msdn.microsoft.com/en-us/library/windows/hardware/mt187909(v=vs.85).aspx. This issue not occurs on Windows 10 x64 RS2. Below is snippet from memory dump analyze:

The test driver was named UCM_Test.
1: kd> kb
Call Site
nt!KeBugCheckEx
nt!PspSystemThreadStartup$filt$0+0x44
nt!_C_specific_handler+0x9f
nt!RtlpExecuteHandlerForException+0xd
nt!RtlDispatchException+0x430
nt!KiDispatchException+0x144
nt!KiExceptionDispatch+0xce
nt!KiPageFault+0x217
UcmCx!GetConnectorById+0x22
UcmCx!imp_UcmConnectorCreate+0x15f
UCM_Test!UcmConnectorCreate+0x56 [c:\program files (x86)\windows kits\10\include\10.0.15063.0\km\ucm\1.0\ucmmanager.h @ 284]
UCM_Test!EvtDevicePrepareHardware+0xb8 [e:\study\ucm_test\ucm_test\device.c @ 201]
Wdf01000!FxPnpDevicePrepareHardware::InvokeClient+0x28 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 347]
Wdf01000!FxPrePostCallback::InvokeStateful+0x5a [minkernel\wdf\framework\shared\irphandlers\pnp\cxpnppowercallbacks.cpp @ 467]
Wdf01000!FxPnpDevicePrepareHardware::Invoke+0x17 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 321]
Wdf01000!FxPkgPnp::PnpPrepareHardware+0xdf [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 3599]
Wdf01000!FxPkgPnp::PnpEventHardwareAvailable+0x7a [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1399]
Wdf01000!FxPkgPnp::PnpEnterNewState+0xc9 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1234]
Wdf01000!FxPkgPnp::PnpProcessEventInner+0x1a1 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 1150]
Wdf01000!FxPkgPnp::_PnpProcessEventInner+0x58 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpstatemachine.cpp @ 981]
Wdf01000!FxEventQueue::EventQueueWorker+0x83 [minkernel\wdf\framework\shared\irphandlers\pnp\eventqueue.cpp @ 277]
Wdf01000!FxWorkItemEventQueue::_WorkItemCallback+0x9f [minkernel\wdf\framework\shared\irphandlers\pnp\km\eventqueuekm.cpp @ 110]
nt!IopProcessWorkItem+0xfb
nt!ExpWorkerThread+0xf5
nt!PspSystemThreadStartup+0x47
nt!KiStartSystemThread+0x16

Please support. Any thought would be appreciated.

On 11/12/2017 11:45 PM, xxxxx@gmail.com wrote:

Hi, I’m upgrade to Windows 10 x64 RS3 and got BSOD from one of my old driver. Analyzing the memory dump point out that driver UCMCx.sys caused the BSOD when create UCM Connecter. The UCM Initialization was follow guideline on MSDN here: https://msdn.microsoft.com/en-us/library/windows/hardware/mt187909(v=vs.85).aspx. This issue not occurs on Windows 10 x64 RS2.

You’re calling this a UCM bug, but the crash happened when you call
UcmConnectorCreate.  You should triple-check to make sure all the
parameters you are passing to UcmConnectorCreate are correct, and check
the documentation to make sure nothing changed in that area.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Tim for your reply.
I do some other experiment and seem like the error was because the UcmCx.sys cannot be unloaded properly.

================
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS (ce)
A driver unloaded without cancelling timers, DPCs, worker threads, etc.
The broken driver’s name is displayed on the screen and saved in
KiBugCheckDriver.
Arguments:
Arg1: fffff8004bced4b0, memory referenced
Arg2: 0000000000000010, value 0 = read operation, 1 = write operation
Arg3: fffff8004bced4b0, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, Mm internal code.

TRAP_FRAME: ffff810d4eb48600 – (.trap 0xffff810d4eb48600)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8004bced4b0 rbx=0000000000000000 rcx=ffffd88eabc03318
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8004bced4b0 rsp=ffff810d4eb48798 rbp=ffff810d4eb48819
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
<unloaded_ucmcx.sys>+0x1d4b0:
fffff8004bced4b0 ?? ???<br>Resetting default scope<br><br>IP_MODULE_UNLOADED: <br>UcmCx.sys+1d4b0<br>fffff8004bced4b0 ?? ???

LAST_CONTROL_TRANSFER: from fffff80046639d95 to fffff800465f27d0

STACK_TEXT:
ffff810d4eb48378 fffff80046639d95 : 0000000000000050 fffff8004bced4b0 0000000000000010 ffff810d4eb48600 : nt!KeBugCheckEx
ffff810d4eb48380 fffff8004651ba97 : 0000000000000010 fffff8004bced4b0 ffff810d4eb48600 ffff810d4eb48520 : nt!MiSystemFault+0x100e85
ffff810d4eb48420 fffff800465fc372 : 0000000000000000 0000000000000000 0000000000000000 fffff800465139f6 : nt!MmAccessFault+0xae7
ffff810d4eb48600 fffff8004bced4b0 : fffff800469c9b3e 0000000000000000 0000000000000009 ffffc288982115c0 : nt!KiPageFault+0x132
ffff810d4eb48798 fffff800469c9b3e : 0000000000000000 0000000000000009 ffffc288982115c0 0000000000000090 : <unloaded_ucmcx.sys>+0x1d4b0
ffff810d4eb487a0 fffff800469c98f5 : ffffd88eabc032e0 ffffc288928cbe70 ffffd88eabc032e0 ffffc288928cbe70 : nt!EtwpSendDataBlock+0xfa
ffff810d4eb48880 fffff800469c94a5 : fffff78000000380 fffff78000000380 ffffc288928cbe70 ffffc288926b1000 : nt!EtwpClearSessionAndUnreferenceEntry+0x2a9
ffff810d4eb48950 fffff800469cdd24 : 0000000000000000 ffffc28899c39040 ffffc288926b1000 01d35cf527a297a3 : nt!EtwpDisableTraceProviders+0x71
ffff810d4eb489a0 fffff800469cd67f : ffffc28899c39040 ffffc288926b1000 ffff810d4eb48a60 0000000000000019 : nt!EtwpStopLoggerInstance+0x4c
ffff810d4eb489d0 fffff80046bce872 : 0000000000000019 ffffc288926b1000 ffffc288926f9d00 ffffc28899c39040 : nt!EtwpStopTrace+0xff
ffff810d4eb48a40 fffff800468b6a61 : ffffc2889ac0d700 fffff800468b6870 ffffc288926f9d20 fffff800467edf20 : nt!EtwShutdown+0x122
ffff810d4eb48b40 fffff800464e9645 : ffffc288926f9d20 ffffc288926f9d00 ffffc288926f9d00 ffffc288926f9d20 : nt!PopGracefulShutdown+0x1f1
ffff810d4eb48b80 fffff800465723a7 : ffffc2889ac06640 0000000000000080 ffffc288926b8480 ffffc2889ac0d700 : nt!ExpWorkerThread+0xf5
ffff810d4eb48c10 fffff800465f7d66 : fffff800456a7180 ffffc2889ac0d700 fffff80046572360 0000000000000000 : nt!PspSystemThreadStartup+0x47
ffff810d4eb48c60 0000000000000000 : ffff810d4eb49000 ffff810d4eb43000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
============================

I test with a very simple driver which only call UcmInitializeDevice and UcmConnectorCreate with corresponding WdfObjectDelete to release the connector.
Everythings work fine until I restart the test machine and bugcheck occurs.

My question is, is there any other way to release/uninitialized UCM module? I only call WdfObjectDelete on Release HW and it work fine on RS2.

Please advice.

Many thanks!</unloaded_ucmcx.sys></unloaded_ucmcx.sys>

On Nov 14, 2017, at 12:19 AM, xxxxx@gmail.com wrote:
>
> Thanks Tim for your reply.
> I do some other experiment and seem like the error was because the UcmCx.sys cannot be unloaded properly.

This is an entirely different crash dump from the one you posted first.

> I test with a very simple driver which only call UcmInitializeDevice and UcmConnectorCreate with corresponding WdfObjectDelete to release the connector.
> Everythings work fine until I restart the test machine and bugcheck occurs.

Of course. Did you read the documentation?

The parent object is WdfDevice. You can set the ParentObject member of WDF_OBJECT_ATTRIBUTES https: to NULL or the WDFDEVICE handle. The connector object gets deleted when the parent WDFDEVICE object gets deleted.
YOU do not call WdfObjectDelete. It will be done automatically.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</https:>

Hi Tim, thanks for your advice. I spent some days to research and reviewing both code and document but not yet found information about unload of Ucmcx.sys or what need to do before unload my driver (UCM_Test).
For the testing purpose, after create ucm connector at PrepareHardware I did nothing at Release Hardware/D0Exit to let framework free resource by it own. However, after unload driver successfully, the BSOD keep appear after restart machine.
The bugcheck said about some pending operation has not been canceled before driver Ucmcx.sys was unload but I don’t find any document about doing that action at client driver (UCM_Test).

Any advice would be very much appreciated as I am out of ideas.

Thanks and Best Regards,

Hi Tim and all,

Thanks for your support/advice. We test the driver on Windows 10 RS4 build 17064 and the BSOD not occurs anymore.

Thanks and Best Regards.