Windows USB driver for SL8082T module crashed

My customer encountered an issue using a modem that uses the SL8082T module on Windows 2016. Windows crashed and the issue appears to be with swiwdmbx64.sys. I’m using the USB driver from this page -,-d-,1_sl808xt-series/#sthash.CIVMfD1P.H7ycrmJx.dpbs

Has anyone encountered a similar situation and if there’s a way to avoid this, or at least prevent Windows from crashing? Or is there another driver that I can use? I know this is a tricky question, but I would appreciate any pointers. Thank you very much.

!analyze -show


An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.


Arg1: 0000000000000040, memory referenced

Arg2: 0000000000000002, IRQL

Arg3: 0000000000000001, bitfield :

          bit 0 : value 0 = read operation, 1 = write operation

          bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)

Arg4: fffff8028b64530e, address which referenced memory

!mex.t ffffbb8b92805040

Process Thread CID UserTime KernelTime ContextSwitches Wait Reason Time State

System (ffffbb8b88899040) ffffbb8b92805040 (E|K|W|R|V) 4.407c 0 156ms 28944 Executive 46ms Running on processor 1


Current Base Decrement ForegroundBoost IO Page

12      12   0         0               0  5

Child-SP Return Call Site Source

0 ffffce01e6e76158 fffff8028b76ce29 nt!KeBugCheckEx

1 ffffce01e6e76160 fffff8028b76b407 nt!KiBugCheckDispatch+0x69

2 ffffce01e6e762a0 fffff8028b64530e nt!KiPageFault+0x247

3 ffffce01e6e76430 fffff80a9b518dfd nt!IopfCompleteRequest+0x42e

4 ffffce01e6e76550 fffff8028b644ff2 swiwdmbx64+0x8dfd

5 ffffce01e6e765c0 fffff80a980a6907 nt!IopfCompleteRequest+0x112

6 (Inline) ---------------- Wdf01000!FxIrp::CompleteRequest+0xd d:\rs1\minkernel\wdf\framework\shared\inc\private\km\fxirpkm.hpp @ 75

7 ffffce01e6e766e0 fffff80a980b21c4 Wdf01000!FxRequest::CompleteInternal+0x247 d:\rs1\minkernel\wdf\framework\shared\core\fxrequest.cpp @ 871

8 (Inline) ---------------- Wdf01000!FxRequest::CompleteWithInformation+0x18 d:\rs1\minkernel\wdf\framework\shared\inc\private\common\fxrequest.hpp @ 820

9 ffffce01e6e76790 fffff80a980b243c Wdf01000!FxIoQueue::CancelForQueue+0x94 d:\rs1\minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 4433

a ffffce01e6e767f0 fffff80a980b1faf Wdf01000!FxIoQueue::QueuePurge+0x1b8 d:\rs1\minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 4054

b ffffce01e6e76860 fffff80a9a234c0c Wdf01000!imp_WdfIoQueuePurge+0x3f d:\rs1\minkernel\wdf\framework\shared\irphandlers\io\fxioqueueapi.cpp @ 1261

c ffffce01e6e768a0 fffff80a9a29381d USBXHCI!Endpoint_UcxEvtEndpointPurge+0x14c

d ffffce01e6e76900 fffff80a9a2926e1 ucx01000!UcxEndpointStateEntryFunc_Purging1+0x1d

e ffffce01e6e76930 fffff80a9a2888c5 ucx01000!StateMachineEngine_EventAdd+0x3e1

f ffffce01e6e76990 fffff80a9a2897fc ucx01000!UsbDevice_CallAddEventForAllEndpointsWithPendingOperationSet+0x195

10 ffffce01e6e76a00 fffff80a9a28ab0a ucx01000!UsbDevice_PurgeFromHub+0x90

11 ffffce01e6e76a40 fffff80a980ab609 ucx01000!UsbDevice_EvtMgmtIoInternalDeviceControl+0x76a

12 (Inline) ---------------- Wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x43 d:\rs1\minkernel\wdf\framework\shared\inc\private\common\fxioqueuecallbacks.hpp @ 267

13 ffffce01e6e76c20 fffff80a980aa7aa Wdf01000!FxIoQueue::DispatchRequestToDriver+0x289 d:\rs1\minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 3340

14 ffffce01e6e76cc0 fffff80a980bb5d2 Wdf01000!FxIoQueue::DispatchEvents+0x3aa d:\rs1\minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 3122

15 (Inline) ---------------- Wdf01000!FxIoQueue::QueueRequest+0x86 d:\rs1\minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 2364

16 (Inline) ---------------- Wdf01000!FxPkgIo::DispatchStep2+0x498 d:\rs1\minkernel\wdf\framework\shared\irphandlers\io\fxpkgio.cpp @ 469

17 ffffce01e6e76d90 fffff80a9a2855b8 Wdf01000!imp_WdfDeviceWdmDispatchIrpToIoQueue+0x622 d:\rs1\minkernel\wdf\framework\shared\core\km\fxdeviceapikm.cpp @ 494

18 ffffce01e6e76e70 fffff80a980a3b8c ucx01000!RootHub_Pdo_EvtInternalDeviceControlIrpPreprocessCallback+0x768

19 (Inline) ---------------- Wdf01000!PreprocessIrp+0x34 d:\rs1\minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1502

1a (Inline) ---------------- Wdf01000!DispatchWorker+0x776 d:\rs1\minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1565

1b (Inline) ---------------- Wdf01000!FxDevice::Dispatch+0x782 d:\rs1\minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1586

1c ffffce01e6e76f00 fffff80a980aec04 Wdf01000!FxDevice::DispatchWithLock+0x7ec d:\rs1\minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1430

1d (Inline) ---------------- Wdf01000!FxIoTarget::Send+0xd d:\rs1\minkernel\wdf\framework\shared\inc\private\km\fxiotargetkm.hpp @ 267

1e ffffce01e6e76ff0 fffff80a9a3dcf36 Wdf01000!imp_WdfRequestSend+0x164 d:\rs1\minkernel\wdf\framework\shared\core\fxrequestapi.cpp @ 2101

1f ffffce01e6e77080 fffff80a9a3df0bc UsbHub3!HUBUCX_SubmitUcxIoctl+0x16a

20 ffffce01e6e77110 fffff80a9a3d759d UsbHub3!HUBUCX_PurgeDeviceIoUsingUCXIoctl+0x70

21 ffffce01e6e77150 fffff80a9a3c90f3 UsbHub3!HUBDSM_PurgingDeviceIoOnDetachInConfigured+0x1d

22 ffffce01e6e77180 fffff80a9a3ca1f6 UsbHub3!HUBSM_ExecuteEntryFunctionsAndPushPopStateMachinesForCurrentState+0x4b

23 ffffce01e6e77210 fffff80a9a3c9bde UsbHub3!HUBSM_RunStateMachine+0x5f6

24 ffffce01e6e772a0 fffff80a9a3e5e8d UsbHub3!HUBSM_AddEvent+0x3fe

25 ffffce01e6e772f0 fffff80a9a3cdaa0 UsbHub3!HUBMISC_DetachDevice+0x21

26 ffffce01e6e77320 fffff80a9a3c90f3 UsbHub3!HUBPSM20_DetachingDeviceFromPortOnCycleOnHubStop+0x10

27 ffffce01e6e77350 fffff80a9a3ca1f6 UsbHub3!HUBSM_ExecuteEntryFunctionsAndPushPopStateMachinesForCurrentState+0x4b

28 ffffce01e6e773e0 fffff80a9a3c97c2 UsbHub3!HUBSM_RunStateMachine+0x5f6

29 ffffce01e6e77470 fffff80a9a28fac4 UsbHub3!HUBSM_EvtSmWorkItem+0x42

2a ffffce01e6e774a0 fffff8028b6b6011 ucx01000!Controller_ForwardProgressWorkItemCallback+0x5c

2b ffffce01e6e774d0 fffff8028b678bd9 nt!IopProcessWorkItem+0x81

2c ffffce01e6e77540 fffff8028b6c9765 nt!ExpWorkerThread+0xe9

2d ffffce01e6e775d0 fffff8028b7671a6 nt!PspSystemThreadStartup+0x41

2e ffffce01e6e77620 0000000000000000 nt!KiStartSystemThread+0x16

lmvm swiwdmbx64

Browse full module list

start end module name

fffff80a9b510000 fffff80a9b52ab00 swiwdmbx64 (no symbols)

Loaded symbol image file: swiwdmbx64.sys

Image path: \SystemRoot\System32\drivers\swiwdmbx64.sys

Image name: swiwdmbx64.sys

Hi @clickndeploy,

On page,-d-,54,-d-,0,-d-,a1-for-sl808xt_bt/#sthash.HU2ygS75.dpbs, the latest FW was published in 2016, I think that SL808xT series was end of sale and end of life long time ago.
So I think you should consider to change to the HLxxxx series having similar specifications to replace the SL808xT series to receive the better supporting.
You can find your Sierra Wireless distributor and reseller in link : Authorized Distributors | Sierra Wireless


Thanks, but would the firmware affect the USB driver and crash Windows? The module itself did not crash.

Hi @clickndeploy,

Following logically, module only receive command from PC, it does not send anything to PC. So I think FW of module cannot cause your Windows crash.
Did you try attach this module to another Windows? And did this issue happen again?


Yes, the crash is caused by the USB driver, not the module itself. The user has other Windows 2016 with the same module and using same driver but has not encountered this issue. HP which supplied the server says that the driver is too old and may not be compatible with Windows 2016. This issue also only happened after a couple months of use. The server is running a critical system. If changing the USB driver is not possible, I wonder if there’s any configuration that can prevent this from happening?

will you consider to use Linux PC?

I remember no problem is found on Linux ubuntu.