The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
computer rebooting -- MB, NIC or something else?
Nerissa
Registered User regular
Registered User regular
We have a MyBook external HD connected directly to our router. Over the past couple of days, I've been setting up a password-protected share and transferring my work files over to it so that in the event of total system failure (i.e. power supply going out, etc.) I can still work on another computer.
However, when I access these folders via my work computer, it will occasionally cause the computer to reboot, which is a pain. (Sometimes just opening a folder, sometimes trying to run a program I wrote, mostly when it is trying to overwrite a file such as a re-compile).
Note that this ONLY happens when accessing stuff on the external HD, although I haven't really tried accessing any other shares on the network (we really don't have many others now that we got the external). It does not happen with any other network access (browser, download, connecting to VPN, and pcAnywhere all seem to work ok) It ONLY happens with my work computer, so I'm pretty sure it's the computer not the external drive.
I am NOT running a wireless card on the work machine, only a 10/100 standard LinkSys card. I've got a hub between the computer and the router, and another computer connected to the same hub has no problem.
However, when I access these folders via my work computer, it will occasionally cause the computer to reboot, which is a pain. (Sometimes just opening a folder, sometimes trying to run a program I wrote, mostly when it is trying to overwrite a file such as a re-compile).
Note that this ONLY happens when accessing stuff on the external HD, although I haven't really tried accessing any other shares on the network (we really don't have many others now that we got the external). It does not happen with any other network access (browser, download, connecting to VPN, and pcAnywhere all seem to work ok) It ONLY happens with my work computer, so I'm pretty sure it's the computer not the external drive.
I am NOT running a wireless card on the work machine, only a 10/100 standard LinkSys card. I've got a hub between the computer and the router, and another computer connected to the same hub has no problem.
Nerissa on
0
Posts
If it's a Windows system that's crashing, check your C:\Windows\Minidump directory for memory dumps that may have been created at the time of the crash. If you have a kernel debugger....um...know what, just post them somewhere and I can show you what they say about the cause of the crashes.
I believe that it is using SMB, but I'm honestly not 100% sure... I plug it in and use the router configuration pages to set up shares, users, etc. so the underlying system could be magic for all I could swear to.
The system that is crashing is XP Pro -- I found the memory dumps, but obviously opening them in a plain text editor doesn't make them very readable. Is there something I can download from somewhere (if there isn't a decent free tool, I'm willing to pay a little bit, but not a lot) to try to decypher them? I also have Visual Studio 6 (with all of the tools up to Enterprise level) on this machine, so if there is something in there I can use, that would work too.
How do you access the remote drive?
A) It's a "lettered" network drive (eg G:\ or N:\)
C) It's accessed via FTP (eg ftp://xxx.xxx.xxx.xxx/mysecurefolder)
D) Other.
It's something I will be accessing frequently throughout the work day, so I have it set up as a mapped drive (i.e. option A). Is there really a functional difference (other than convenience and potential security risks) between a mapped drive and using the UNC path?
If you use it as a mapped network drive, I think Windows handles the interface via Logical Disk Management and the Workstation service, I think there may be a slight (tiny) amount of additional overhead when using that method versus a straight UNC path.
I'd say try it for a week using the mapped drive, then try it for a week using a shortcut on your desktop pointing to the UNC path, and then decide if either is obviously more stable than the other.
kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f) This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc) Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes: If kv shows a taskGate use .tss on the part before the colon, then kv. Else if kv shows a trapframe use .trap on that value Else .trap on the appropriate frame will show where the trap was taken (on x86, this will be the ebp that goes with the procedure KiTrap) Endif kb will then show the corrected stack. Arguments: Arg1: 00000008, EXCEPTION_DOUBLE_FAULT Arg2: 80042000 Arg3: 00000000 Arg4: 00000000 Debugging Details: ------------------ ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ***** Kernel symbols are WRONG. Please fix symbols to do analysis. MODULE_NAME: AN983 FAULTING_MODULE: 804d7000 nt DEBUG_FLR_IMAGE_TIMESTAMP: 3bd7b441 BUGCHECK_STR: 0x7f_8 CUSTOMER_CRASH_COUNT: 3 DEFAULT_BUCKET_ID: WRONG_SYMBOLS LAST_CONTROL_TRANSFER: from 81a6d470 to f8627d71 STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. f262effc 81a6d470 00210032 00790053 00490073 AN983+0x1d71 f262f000 00210032 00790053 00490073 00410050 0x81a6d470 f262f004 00790053 00490073 00410050 00640064 0x210032 f262f008 00490073 00410050 00640064 00650072 0x790053 f262f00c 00410050 00640064 00650072 00730073 0x490073 f262f010 00640064 00650072 00730073 00320033 0x410050 f262f014 00650072 00730073 00320033 00630000 0x640064 f262f018 00730073 00320033 00630000 006d006f 0x650072 f262f01c 00320033 00630000 006d006f 00740063 0x730073 f262f020 00630000 006d006f 00740063 0033006c 0x320033 f262f024 006d006f 00740063 0033006c 002e0032 0x630000 f262f028 00740063 0033006c 002e0032 006c0064 0x6d006f f262f02c 0033006c 002e0032 006c0064 0000006c 0x740063 f262f030 002e0032 006c0064 0000006c 00790053 0x33006c f262f034 006c0064 0000006c 00790053 00500073 0x2e0032 f262f038 00000000 00790053 00500073 00670061 0x6c0064 STACK_COMMAND: kb FOLLOWUP_IP: AN983+1d71 f8627d71 55 push ebp SYMBOL_STACK_INDEX: 0 FOLLOWUP_NAME: MachineOwner IMAGE_NAME: AN983.sys SYMBOL_NAME: AN983+1d71 BUCKET_ID: WRONG_SYMBOLS Followup: MachineOwner ---------So, it's a third-party driver problem, and the solution would be "get a fixed version of this driver" -- if this company was still in business. As is, you're going to have a hell of a time finding a driver update online. I Googled it and came up with no official support page for this manufacturer.
I tried a reformat but it crashed right after successfully installing windows.
Here is my debug
Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\Minidump\Mini041107-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805531a0
Debug session time: Wed Apr 11 02:02:13.250 2007 (GMT-4)
System Uptime: 0 days 6:22:02.905
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
....................................................................................................................
Loading User Symbols
Loading unloaded module list
..........
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, 805d3a97, b4c15af8, 0}
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : win32k.sys ( win32k+d2b9 )
Followup: MachineOwner
Any help would be greatly appreciated as it happens 2-3 times a day.
Could it be an on-board ethernet adapter? If you are using a LinkSys card that is good news, it means you can possibly just disable this ADMTek adapter in the Device Manager and delete its driver (AN983.sys) and just never worry about it again.
Did you run the command "!analyze -v" in WinDbg? Your problem looks a little tougher since the dump file is pointing at win32k.sys, a Microsoft driver. Microsoft drivers are usually the last thing I blame when looking at a problem like this (it's just been my experience in debugging drivers, you blame MS last). So even though WinDbg says the crash was caused by win32k.sys, the actual problem probably lies in some other component that win32k.sys interacts with, depends upon, or is servicing at the time of the crash.
Win32k.sys is the Kernel side of the Win32 "subsystem" in the Windows kernel. Its area of responsibility involves the infrastructure of the graphical user interface. When people have a problem with this driver, usually it is actually their graphics card or driver that is the problem. If you can, check to see that you are using the latest video card drivers available. If this doesn't fix it, at least you know what to focus on -- the video card.
First off though, make sure you don't have a more general issue. Run MemTest86 (download the free ISO, burn the CD, boot from that CD, let it run the diagnostics). If you have memory errors, your memory timings might be off (fixable with a BIOS setting), or you might be running with non-recommended RAM for the motherboard, or just plain defective RAM.
As near as I can tell, the MB doesn't have on-board ethernet ... The only thing I'm seeing under net Network Adapters in the device manager is my LinkSys card, my disabled wireless card, also LinkSys (which we tried to use when we first upgraded the router, but it failed in bad weather, which was unacceptable), and a 1394 adapter, although I don't see a FireWire connector anywhere either.
Now that I think about it, this may very well be the only computer we have left NOT using either wireless or on-board ethernet, so I am starting to suspect it's a combination of the XP-included drivers with the LinkSys card.
If you run System Information (from Start Menu->Programs->Accessories->System), go to Components, then Network, then Adapter, can you find any adapter that thinks it is using AN983.sys for its driver?
The driver "AN983.sys" does not ship with the OS. I am starting to think LinkSys uses an ADMTek chip on their cards. Do you have the Linksys LNE100TX Fast Ethernet Adapter? This model turns up alongside "AN983.sys" in Googling. If that's what you have, maybe you could download the latest driver from LinkSys and give that a shot. As for which one of those downloads is the correct one for you, it looks like you have to look at the card itself for the version you have.
It just occurred to me how bizarre it is, what you said. The LinkSys wireless card would not work when it rained outside? Seriously?
My card says it's LNE100TX v4.1 so I download the appropriate driver pack and extract it.
I run the dos-based diagnostic and it says it can't find the card. I've just used the card to copy the drivers from the machine where I downloaded them, so I know it's seated properly, etc.
It also doesn't seem to have XP drivers... Windows drivers I see are NT, ME, 2000, 98, 95, and (!) WFW3.11
I'm thinking it's time to shell out the $10 or so for a new network card that comes with XP drivers.
Well, it wasn't so much that it didn't work at all, it was more like the connection kept going up and down and my bandwidth dropped pretty harsh, but with several pcAnywhere sessions open at once much of the time, this really wasn't going to work for me. And it was a pretty heavy storm, like lightning and all.
It's a Wireless-B card, connected to a Wireless-G router (the G card wouldn't stay connected for more than a few seconds at a time on this machine, I suspect it was a bad card). It worked wonderfully until the first thunderstorm hit. I'm in Florida, it's not like thunderstorms aren't going to be a daily occurrence once summer rolls around.
Also, I'm notoriously bad for electronic devices. I once owned a cheapy digital watch that ran twice as fast as it should have, but only when I was actually wearing it. So this may all actually be my fault. :P
...and yes, System Information shows the AN983 driver for the LinkSys card.
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000020, a pool block header size is corrupt.
Arg2: 89649550, The pool entry we were looking for within the page.
Arg3: 89649590, The next pool entry.
Arg4: 0a080005, (reserved)
Debugging Details:
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
***** 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!_POOL_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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!_POOL_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** 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!_POOL_TRACKER_BIG_PAGES ***
*** ***
*************************************************************************
Cannot get _POOL_TRACKER_BIG_PAGES type size
MODULE_NAME: nt
FAULTING_MODULE: 804d7000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1d
BUGCHECK_STR: 0x19_20
POOL_ADDRESS: 89649550
CUSTOMER_CRASH_COUNT: 2
DEFAULT_BUCKET_ID: WRONG_SYMBOLS
LAST_CONTROL_TRANSFER: from 80543c86 to 804f8925
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
bad0ba48 80543c86 00000019 00000020 89649550 nt+0x21925
bad0ba98 ba5566ad 89649558 00000000 bad0baf8 nt+0x6cc86
bad0baac ba5834fd 89649558 89cf0260 e15e1d20 Ntfs+0x66ad
bad0bad0 ba55657a 8901b008 bad0baf8 bad0bb03 Ntfs+0x334fd
bad0bb1c ba577d00 8901b008 89cf0100 e34ecc58 Ntfs+0x657a
bad0bb74 ba552759 8901b008 e34ecd20 00000000 Ntfs+0x27d00
bad0bba0 ba5756eb 8901b008 014ecd20 00000000 Ntfs+0x2759
bad0bc24 ba57548a 8901b008 e34ecd20 e34ecc58 Ntfs+0x256eb
bad0bcc4 804eddf9 89cf0020 899de780 89d3a740 Ntfs+0x2548a
bad0bcdc 804eddf9 89d369a0 899de780 899de780 nt+0x16df9
bad0bd24 805af547 00a83510 89a834f8 00000000 nt+0x16df9
bad0bd40 80521e47 89a83510 00000000 00000000 nt+0xd8547
bad0bd64 80507192 80557838 89336398 806d02d0 nt+0x4ae47
bad0bd8c 80508936 e2ba6360 00000000 89e3e378 nt+0x30192
bad0bdac 805c4a06 00000000 00000000 00000000 nt+0x31936
bad0bddc 80540fa2 80508898 00000000 00000000 nt+0xeda06
00000000 00000000 00000000 00000000 00000000 nt+0x69fa2
STACK_COMMAND: kb
FOLLOWUP_IP:
nt+21925
804f8925 5d pop ebp
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: ntoskrnl.exe
SYMBOL_NAME: nt+21925
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
Any more insight would be greatly appreciated.
Well, since we've gone to all this trouble, maybe there's still hope. I just downloaded this package for 4.1 myself to look. Ugh...g-h-e-t-t-o...and yea you're right, no XP drivers. But, you should be able to install the Windows 2000 driver and not have any issues. It will at least get rid of that disaster of a driver ADMTek wrote.
Thanks muchly for all of your help
!@#$%;^&*()
Oddly enough, the v4 card with the an983 driver is still showing up as the first thing under system info, and I had to scroll WAY down to find the actual (new) card, but it is, in fact, there.
Could it be an actual hardware problem, like with the PCI slot or something?
Alternately, maybe it's time to change brands...