Laptop BSOD's near cable modem?!

[Gerbil333]

We just moved into a new apartment. Since I've owned laptops (only the past 4 years), I've had DSL shared by a WRT54G running DD-WRT and a Netgear MR814 gigabit switch.

Anyway, we had 3mb cable installed on Monday and my trusty IBM Thinkpad T41 was sitting on the floor about 2-3 feet from the new Motorola cable modem, WRT54G, and MR814. About 30 minutes after the cable was set up, I picked up my laptop and lifted the lid: BSOD and reboot.

I'd never had a problem with the laptop until that moment. Well, another BSOD popped up not 5 minutes after I set it down in the same spot on the floor near the cable modem. I ran memtest86+ for 2 hours with the laptop in a different location, further from the modem: no errors. I left town Monday evening with the laptop and it's been running 24x7, rock solid.

I'll experiment more later, but has anyone experienced anything like this? I know it's plausible that RF/EMI can cause these problems. If that's the case, I guess I'll build a Faraday cage for the modem...


From XP's Computer Management, both BSOD's show up as Category "(102)" and Event 1003:
- - - - - - - - - - - - - - - - - - - -

Error code 1000008e, parameter1 c0000005, parameter2 8054b234, parameter3 b4a38bf8, parameter4 00000000.

 

[dclive]

Originally posted by: Gerbil333
We just moved into a new apartment. Since I've owned laptops (only the past 4 years), I've had DSL shared by a WRT54G running DD-WRT and a Netgear MR814 gigabit switch.

Anyway, we had 3mb cable installed on Monday and my trusty IBM Thinkpad T41 was sitting on the floor about 2-3 feet from the new Motorola cable modem, WRT54G, and MR814. About 30 minutes after the cable was set up, I picked up my laptop and lifted the lid: BSOD and reboot.

I'd never had a problem with the laptop until that moment. Well, another BSOD popped up not 5 minutes after I set it down in the same spot on the floor near the cable modem. I ran memtest86+ for 2 hours with the laptop in a different location, further from the modem: no errors. I left town Monday evening with the laptop and it's been running 24x7, rock solid.

I'll experiment more later, but has anyone experienced anything like this? I know it's plausible that RF/EMI can cause these problems. If that's the case, I guess I'll build a Faraday cage for the modem...


From XP's Computer Management, both BSOD's show up as Category "(102)" and Event 1003:
- - - - - - - - - - - - - - - - - - - -

Error code 1000008e, parameter1 c0000005, parameter2 8054b234, parameter3 b4a38bf8, parameter4 00000000.

Analyze the dumps and you'll see what's causing the issue. Post the output of !analyze -v here and we'll take a look at it - for both dumps. Read my website (see .sig) for more info.

 

[Gerbil333]

I tried following your site. Is the symbols path supposed to be "SRV*c:\debug*http://msdl.microsoft.com/download/symbols" ?

Winddbg seems to think there's still something wrong with the symbols. Regardless, attached are results from !analyze -v:

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: bf8f5044, The address that the exception occurred at
Arg3: b48dab08, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

MODULE_NAME: win32k

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 47e0df7d

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
win32k+f5044
bf8f5044 ffb094010000 push dword ptr [eax+194h]

TRAP_FRAME: b48dab08 -- (.trap 0xffffffffb48dab08)
ErrCode = 00000000
eax=000003f6 ebx=00000000 ecx=e2c64aa8 edx=b48dabc8 esi=e2c64aa8 edi=e2c44aa8
eip=bf8f5044 esp=b48dab7c ebp=b48dab84 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
win32k+0xf5044:
bf8f5044 ffb094010000 push dword ptr [eax+194h] ds:0023:0000058a=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from bf845f17 to bf8f5044

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b48dab84 bf845f17 e2c64aa8 e2c44aa8 00000000 win32k+0xf5044
b48dabd8 bf846f9d 00000000 b48dac1c bf8bbd67 win32k+0x45f17
b48dabe4 bf8bbd67 bc511008 89566748 e2c64aa8 win32k+0x46f9d
b48dac1c bf819ebd 00000001 b48dac44 bf819f81 win32k+0xbbd67
b48dac28 bf819f81 894f3748 00000001 00000000 win32k+0x19ebd
b48dac44 8056a2cf 894f3748 00000001 89492a68 win32k+0x19f81
b48dacf0 80584ca6 c0000005 b48dad4c 804e60f1 nt+0x932cf
b48dacfc 804e60f1 89492a68 b48dad48 b48dad3c nt+0xadca6
b48dad4c 804de855 00000001 00000000 b48dad64 nt+0xf0f1
b48dad64 7c90eb94 badb0d00 0012fd20 b4c9cd98 nt+0x7855
b48dad68 badb0d00 0012fd20 b4c9cd98 b4c9cdcc 0x7c90eb94
b48dad6c 0012fd20 b4c9cd98 b4c9cdcc 00000000 0xbadb0d00
b48dad70 b4c9cd98 b4c9cdcc 00000000 00000000 0x12fd20
b48dad74 b4c9cdcc 00000000 00000000 00000000 0xb4c9cd98
b48dad78 00000000 00000000 00000000 00000000 0xb4c9cdcc


STACK_COMMAND: kb

FOLLOWUP_IP:
win32k+f5044
bf8f5044 ffb094010000 push dword ptr [eax+194h]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: win32k+f5044

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: win32k.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

 

[Gerbil333]

The second dump is quite different:

Probably caused by : d347bus.sys ( d347bus+fc3 )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8054b234, The address that the exception occurred at
Arg3: b4a38bf8, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

MODULE_NAME: d347bus

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4128a01d

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
nt+74234
8054b234 897104 mov dword ptr [ecx+4],esi

TRAP_FRAME: b4a38bf8 -- (.trap 0xffffffffb4a38bf8)
ErrCode = 00000002
eax=8978d880 ebx=897ad028 ecx=00000000 edx=00000102 esi=897ad880 edi=000001ff
eip=8054b234 esp=b4a38c6c ebp=b4a38cc0 iopl=0 nv up ei ng nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010287
nt+0x74234:
8054b234 897104 mov dword ptr [ecx+4],esi ds:0023:00000004=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 804eaaff to 8054b234

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b4a38cc0 804eaaff 00000001 00000001 36383356 nt+0x74234
b4a38cdc f75b0fc3 00000001 00000808 36383356 nt+0x13aff
b4a38d18 f75bd725 e1b79798 00129d04 00a38d30 d347bus+0xfc3
b4a38d38 f75bd7bc 00129d2c 00129c9c b4a38d64 d347bus+0xd725
b4a38d64 7c90eb94 badb0d00 00129c84 b4c2cd98 d347bus+0xd7bc
b4a38d68 badb0d00 00129c84 b4c2cd98 b4c2cdcc 0x7c90eb94
b4a38d6c 00129c84 b4c2cd98 b4c2cdcc 00000000 0xbadb0d00
b4a38d70 b4c2cd98 b4c2cdcc 00000000 00000000 0x129c84
b4a38d74 b4c2cdcc 00000000 00000000 00000000 0xb4c2cd98
b4a38d78 00000000 00000000 00000000 00000000 0xb4c2cdcc


STACK_COMMAND: kb

FOLLOWUP_IP:
d347bus+fc3
f75b0fc3 ?? ???

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: d347bus+fc3

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: d347bus.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

 

[dclive]

Your symbols are wrong; fix them by putting that statement in there (I think you had it right) again (follow the guide... you have to do it in that exact order).

Looks like the d347... driver is to blame. Uninstall Alcohol 120% or any similar CDROM/etc. utilities and see if you can still repro the problem.

 

[Gerbil333]

I'll see if I can fix the symbols.

I'm almost positive this is a microwave band interference issue, not a software glitch. The laptop passes memtest86 and it's stable anywhere except near that new cable modem. This screams hardware issue to me.

In the first dump, d347bus.sys was not the issue. The laptop had just made it into XP when the second crash occurred. What this suggests to me is that the d347bus.sys driver happened to be loading while a particularly strong wave of interference struck the machine.

 

[dclive]

It would be a trivial test to uninstall the sw....

 

[tcsenter]

The laptop is overheating when its sitting on the floor.

 

[Gerbil333]

That may be so, but I'm still out of town and the problem hasn't and will not reappear until I'm next to the cable modem back at my new apartment.

I have the laptop's original, factory installation of XP Pro on its original 40GB hard drive (I upgraded to a larger drive the first week). I will see what happens using that setup next to my cable modem.

I do appreciate you're help. I'll post my results once I've solved the problem. As an analog circuit designer, it makes better sense to me to eliminate a source of interference rather than to disable functionality of one of my computers, which has worked perfectly in many different homes/buildings for the year I've owned it.

I'll upload the *.dmp files to my server shortly.

 

[Gerbil333]

Originally posted by: tcsenter
The laptop is overheating when its sitting on the floor.

Nope, it was idling when the BSOD's occurred. It passes memtest86 on the same floor in a different area of the room. Temperatures are all reasonable, if not cool for a laptop.