Ok so I had built this new Fujitsu T901 tablet which was performing pretty well with a quick 256 GB SSD making Windows 7 move along nicely. Sadly I didn’t have a chance to put Windows 8 on this puppy.
So I was demoing some of the best features of Windows 7 when used as a tablet when the customer wanted to try their Telstra 3G card. Now I had been prepared for this and pre-installed the necessary drivers…but as soon as it was plugged in *boom* BSOD!
Oh great. Customer demo. Crashing machines. This looks good. NOT!
This was also happening at the end of a 12 hr work day just itching to extend it even longer…
It was time to test out my recently online Auto-Mini dump analyser https://chentiangemalc.wordpress.com/2012/02/26/announcing-the-auto-mini-dump-analyser/
In a few minutes I got a response from the service.
The bug check code:
This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but … If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is
Arg1: c0000005, The exception code that was not handled
Arg2: 95392b26, The address that the exception occurred at
Arg3: 8a78b608, Exception Record Address
Arg4: 8a78b1e0, Context Record Address
Further information pointed to the driver involved:
LAST_CONTROL_TRANSFER: from 827ba5d8 to 827b9b26
WARNING: Stack unwind information not available. Following frames may be wrong.
8a79372c 827ba5d8 85efc7c8 851857b0 00000000 nusb3xhc+0x12b26
8a793750 827bbf2d 85efc7c8 851857b0 850c1470 nusb3xhc+0x135d8
8a79376c 827bc021 863c7f20 851857b0 85185868 nusb3xhc+0x14f2d
8a793780 827bc097 863c7f20 851857b0 0802c3ef nusb3xhc+0x15021
8a7937bc 82c924bc 863c7e68 851857b0 851858a8 nusb3xhc+0x15097
8a7937d4 8f1df3f3 850c1470 84f29910 86829770 nt+0x3c4bc
8a7937f8 8f1d75bb 863c7e68 851857b0 850c1470 nusb3xhc+0xc3f3
8a793818 8f1d7799 84f29910 851857b0 00000000 nusb3xhc+0x45bb
8a793838 8f1d3cb9 86829770 851857b0 84f29910 nusb3xhc+0x4799
8a79384c 8f1d3de2 84f29910 851857b0 8518588c nusb3xhc+0xcb9
8a793860 8f1d3e59 84f29910 851857b0 05649f84 nusb3xhc+0xde2
8a79389c 82c924bc 84f29858 851857b0 851857b0 nusb3xhc+0xe59
8a7938b4 b2294860 850c1470 85183b70 850c1484 nt+0x3c4bc
8a7938e0 b2294dbf 85183ab8 850c1470 00000001 USBSTOR+0xb860
8a793914 b2297230 85183ab8 85183b70 855a9780 USBSTOR+0xbdbf
8a79397c b22974d7 85183ab8 855a9780 855a98a4 USBSTOR+0xe230
8a793998 82c924bc 855a9880 855a9780 8a793a20 USBSTOR+0xe4d7
8a7939b0 82dfed7c 00000000 84f29858 93c62468 nt+0x3c4bc
8a7939cc 82c6a479 8a7939fc 82c69b67 93c62468 nt+0x1a8d7c
8a793a30 82e04bf8 82c69b67 93c62468 84fb1618 nt+0x14479
8a793a8c 82e04ac1 93c62468 00000022 00000000 nt+0x1aebf8
8a793aa8 82dfd8bd 00000000 00000000 8c1d42c0 nt+0x1aeac1
8a793ca4 82e06685 84fb1618 8c1d42c0 8a793cd0 nt+0x1a78bd
8a793cd8 82c69f56 82db9e80 84bfd020 82d905bc nt+0x1b0685
8a793d00 82cc406b 00000000 00000000 84bfd020 nt+0x13f56
8a793d50 82e64a55 00000001 94f6c584 00000000 nt+0x6e06b
8a793d90 82d16219 82cc3f5e 00000001 00000000 nt+0x20ea55
00000000 00000000 00000000 00000000 00000000 nt+0xc0219
827b9b26 807b1000 cmp byte ptr [ebx+10h],0
STACK_COMMAND: .cxr 0xffffffff8a793220 ; kb
Because Windows 7 doesn’t have native USB 3.0 support you need to use a vendor supplied driver. In this case I had used the vendor supplied SCCM driver package which included a driver for USB 3.0…
There were a few points here:
1) NUSB3XHC.sys was referred to as NEC USB 3.0 Host Controller in device manager
2) An internet research quickly revealed it’s a popular driver for BSOD’ing machines
3) The driver I had imported was not a NEC driver, but a Renesas Electronics driver…
4) It turns out Renesas and NEC merged in 2010 to become Renesas Electronics aka ルネサス エレクトロニクス株式会社 Runesasu Erekutoronikusu Kabushiki Gaisha (source: http://en.wikipedia.org/wiki/Renesas_Electronics)
It seems there was an old driver which installed instead of the driver I had imported:
; Copyright (c) 2008-2010 NEC Electronics Corporation
; INF file for installing USB 3.0 device drivers.
<blah blah blah>
NECEL = “NEC Electronics”
DISKID = “NEC Electronics USB 3.0 Device Driver Installation Disk”
; Host Controller
NUSB3XHC.DeviceDesc = “NEC Electronics USB 3.0 Host Controller“
NUSB3XHC.SvcDesc = “NEC Electronics USB 3.0 Host Controller Driver”
NUSB3\ROOT_HUB30.DeviceDesc = “NEC Electronics USB 3.0 Root Hub”
NUSB3\CLASS_09.DeviceDesc = “NEC Electronics USB Hub”
NUSB3HUB.SvcDesc = “NEC Electronics USB 3.0 Hub Driver”
Compared to INF of my imported driver:
; Copyright (c) 2010 Renesas Electronics Corporation
; INF file for installing USB 3.0 host controller driver.
<blah blah blah>
RENESAS = “Renesas Electronics”
DISKID = “Renesas Electronics USB 3.0 Device Driver Installation Disk”
; Host Controller
NUSB3XHC.DeviceDesc = “Renesas Electronics USB 3.0 Host Controller”
NUSB3XHC.SvcDesc = “Renesas Electronics USB 3.0 Host Controller Driver”
So I uninstalled the USB 3.0 device using device manager and chose option to Delete drivers. Magically my Renesas driver automatically installed. I then removed all traces of the old USB 3.0 driver from our deployment…
Afterwards NEC had been replaced with the new & correct name of the company –Renesas Electronics USB 3.0.
With the new driver installed BSODs were eliminated.
Moral of the story: If you have NEC USB 3.0 drivers maybe they’re out-dated!