T23 with XP/SP2 crashes TOO regularly

[RealBlackStuff]

Lately my T23 is having BSODs of these three types:
19 BAD_POOL_HEADER (most frequent)
51 REGISTRATION_ERROR
8E KERNEL_MODE_EXCEPTION_NOT_HANDLED

I have fully tested the memory sticks (2x512MB) with MEMTEST86+ and MS-Memorytest, fully tested the hard disk (new since February 2007), ran VERIFIER on my XP installation, ran SFC /scannow, ran REGSUPREME PRO on the registry.
There are no 'odd' items in Device Manager.
If I reboot after the crash (usually at first start up in the morning), she normally runs fine for the rest of the day.
I don't know where to find any 'evil' drivers in the MiniDumps that are produced.
I don't play any games on this TP, it's only used for email, web browsing and the occasional Word or Excel document.
As I am in transit between continents, I don't have any other hardware to use for testing, just this T23 (see sig) and a few memory sticks.

Any hints warmly welcomed.

[Harryc]

Some faulty ram can pass memtest. Try one module at a time in different slots.

[jdhurst]

If the problem were the motherboard, say, I don't think it would leave an error trail behind. At least I have not seen that.

So I still think it might be memory or some like device (I know you ran these tests). My T23 had modem, wireless and ethernet on daughter cards (if I remember correctly) and it might be one of these.

For the kernel_mode error, one Google article points to Norton 2005 as a possible culprit (although I have not seen that). Another article points to memory.

[RealBlackStuff]

Like I said, memory fully tested (individually and together in all slot combinations).

just this T23 (see sig) and a few memory sticks.

I meant a few USB memory sticks.

I never had (and never will have) any Norton/Symantec stuff.
Anyone have an insight where exactly to find any faulty drivers in a MiniDump?
That might be very helpful.

[jdhurst]

Check this article:
http://www.networkworld.com/news/2005/0 ... tml?page=3

It points to a tool I don't seem to have, but perhaps it can help.

Another article blames chipset drivers (so try to re-install them), and numerous articles blame memory. Did you try re-seating the memory? (I know you tested it).

... JDH

[GomJabbar]

I don't know if any of the following would apply to your situation or not.

FIX: Error message when you connect a scanner or a digital camera to a computer that is running Windows XP Service Pack 2: "BAD_POOL_HEADER STOP"

Random "0x0000008E" Error Message on a Blue Screen in Windows XP

A "STOP: 0x0000008E" error message occurs when you change the hardware acceleration setting

[RealBlackStuff]

@jdhurst
I found the Debug program, will try that out on the weekend.

@GomJabbar
None of those apply unfortunately.

When testing memory, I reseated/swapped everything.
I ran a full PC-Doctor as well, also no errors.
This can only mean some faulty driver.
So I'm still looking for tips about the MiniDump interpretation.

[Aroc]

Generally with a faulty driver you get STOP errors that are pretty consistent and similar (or at least the same driver image is cited most (if not all) of the time). When you see bizzare random STOP error codes that fail to repeat with a decernable pattern, it tends to be caused by failing hardware, often motherboard or RAM.

You're probably right to suspect a device driver (or even a program like norton that acts like a low-level device driver). Get the support tools (included Kernel Debugger "kd.exe"). You'll also need the i386 folder from the same O/S that generated the dump. It's also helptful to get the symbol files for your platform, but I don't think it's required as you can use the MS-hosted ones. Read MS KB315263 "How to read the small memory dump files that Windows creates for debugging".

1. Open command prompt, cd to the directory with the Debugging Tools, e.g.,
C:\Program Files\Debugging Tools for Windows.

2. Make sure the command prompt window as enough screens buffered so that you can save the output to a text file. 300 lines should be sufficient.

3. Issue the following command:

>C:\Program Files\Debugging Tools for Windows>kd -y srv*c:\windows\symbols*http:/
/msdl.microsoft.com/download/symbols -i c:\i386 -z c:\path\memory.dmp

-replace "c:\windows\symbols" with your actual path to the symbol files
-replace "c:\i386" with your actual path, note the files need to match system that generated the dump
-replace "c:\path\memory.dmp" with the actual path and the name of the memory dump file. ** this can be a network location.

4. You might receive some text containing the following line in its output (scroll up if needed)

Probably caused by : drivername.sys

5.Note the driver name.

6. At the kd> prompt, type, !analyze -v and press enter. (the exclamation point is important)
Scroll up and note some of the information. But likely the same driver will be cited. Note any "followup_IP" or "default_bucket_ID" information, especially if a driver is cited.

7.At the kd> prompt, type, lmtvm drivername (where drivername is the name of the file without the extension) and press enter.
You should receive the file's pathname on the remote server as well as the files data stamp.

0: kd> lmtvm vdtw30
start end module name
bfa3d000 bfab5000 vdtw30 Symbol file: vdtw30.dll
Image path: \SystemRoot\System32\vdtw30.dll
Timestamp: Tue Nov 29 13:31:17 2005 (438C9E75) Checksum: 0007F025

8. Save the screen output for later, paste the output into a document file.
a. Click the upper left hand icon in the title window of the command prompt
b. Click Edit, Select All.
c. Press enter to copy the contents of the (already) highlighted window text to the Clipboard.
d. Open Notepad (or wordpad) and save the text file.

9. Find this driver on the server's file system. Get the file properties (right-click, select properties)
a. Note the file size (in exact bytes, not the rounded megabytes or kilobytes size).
b. Note the version
c. Note the Company Information, if the file is not from Microsoft.

The vendor of the file will likely need to be contacted for an updated version and/or additional troubleshooting steps.

Run all of the mini-dumps (.dmp) you have through the kernel debugger (kd.exe). See if there are any patterns. Generally if a device driver is at fault, it will be referenced in most (if not all) of the mini-dumps.

It could also be dust buildup on CPU or GPU or fan failure, especially if it doesn't crash during, say, the first 10 minutes of being turned on (as an example).

I hope this helps.

[RealBlackStuff]

Thanks Aroc,
this is the first really useful help for BSOD-dumps that I have ever seen anywhere!
I'll have a go at it some time on the weekend.