WinDbg: Unable to get verifier list

[yousuf khan]

I've been attempting to get to the bottom of a recurring BSOD crash
happening on my system. I've already had 4 crashes so far over the past
two weeks. So I've identified that NTOSKRNL.EXE is involved in all of
them so far. It always somewhere in the stack. So I enabled Driver
Verifier on NTOSKRNL, as well as hal.dll, NTFS.SYS, and FLTMGR.SYS which
were also identified on the stack during various of the events.

Okay so I had my latest crash yesterday, and it occurred on NTOSKRNL as
well. The Verifier was already enabled on the system prior to this
crash, and then when go to Windbg and execute the "!verifier" command,
it comes back with the message, "Unable to get verifier list". Why not,
it should be enabled?

When I check them on the command-prompt I get the following output back,
and they confirm that all of the files are being monitored. So can
somebody familiar with Driver Verifier and Windbg help me out here?

Yousuf Khan

***

>verifier /query
10/01/2010, 3:30:34 PM
Level: 0000009B
RaiseIrqls: 314843045
AcquireSpinLocks: 1893615496
SynchronizeExecutions: 0
AllocationsAttempted: 90514901
AllocationsSucceeded: 90514901
AllocationsSucceededSpecialPool: 7614086
AllocationsWithNoTag: 0
AllocationsFailed: 0
AllocationsFailedDeliberately: 0
Trims: 2452146
UnTrackedPool: 2872921

Verified drivers:

Name: ntoskrnl.exe, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 83397
CurrentNonPagedPoolAllocations: 77485
PeakPagedPoolAllocations: 87305
PeakNonPagedPoolAllocations: 77674
PagedPoolUsageInBytes: 49624396
NonPagedPoolUsageInBytes: 11791484
PeakPagedPoolUsageInBytes: 49827760
PeakNonPagedPoolUsageInBytes: 12139000

Name: hal.dll, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 4
PeakPagedPoolAllocations: 8
PeakNonPagedPoolAllocations: 6
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 992
PeakPagedPoolUsageInBytes: 768
PeakNonPagedPoolUsageInBytes: 32784

Name: fltmgr.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 2
CurrentNonPagedPoolAllocations: 7161
PeakPagedPoolAllocations: 16
PeakNonPagedPoolAllocations: 7173
PagedPoolUsageInBytes: 16
NonPagedPoolUsageInBytes: 1166244
PeakPagedPoolUsageInBytes: 3440
PeakNonPagedPoolUsageInBytes: 1169508

Name: ntfs.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 32443
CurrentNonPagedPoolAllocations: 28514
PeakPagedPoolAllocations: 33133
PeakNonPagedPoolAllocations: 29174
PagedPoolUsageInBytes: 9261776
NonPagedPoolUsageInBytes: 1880368
PeakPagedPoolUsageInBytes: 9472944
PeakNonPagedPoolUsageInBytes: 1965028

[jose]

On Jan 10, 4:49

[mark hobley]

Yousuf Khan <bbbl67@yahoo.com> wrote:
> I've been attempting to get to the bottom of a recurring BSOD crash
> happening on my system. I've already had 4 crashes so far over the past
> two weeks. So I've identified that NTOSKRNL.EXE is involved in all of
> them so far.

If you think the problem is with the IBM PC hardware chips, then I would
boot the system with an Ubuntu live CD, and see if that operates normally.
If it does, then the problem that you are experiencing is probably
software related. In my experience, the blue screen of death is usually a
software problem. I have no known fixes for this.

Is this a new system?
Or is it a system that has been working previously and now crashes more often?
Have you changed something on the system?
Has the harware changed?
Has any software been updated? (Beware of automatic updates)
Try disabling some hardware (sound drivers, network interfaces), and switching
to a standard VGA display setting, if the system lets you do this.
(On some systems it is necessary to remove pin 12 from the VGA cable).

> Okay so I had my latest crash yesterday

Some systems do crash several times a day.

If all else fails, I would look at migration to an open source based
system.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

[kai harrekilde-petersen]

Yousuf Khan <bbbl67@spammenot.yahoo.com> writes:

> Mark Hobley wrote:
>>
>> Is this a new system?
>
> No, it's a pretty mature system now. I built it and upgrade it
> myself. It's an AMD A64X2-4200+ w/ 4GB RAM, and it runs in either
> 32-bit WinXP SP3 or 64-bit Ubuntu 9.10.

Are you using ECC-RAM? I've seen 'unexplainable' crashes on an old
non-ECC machine that was caused by memory corruption. The problem
increased over time until I replaced the system with an ECC-enabled
system.

If you don't use ECC, try memtest86 and/or unplugging some of the RAM
modules.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

[jose]

On Jan 10, 11:48

[jose]

On Jan 11, 12:19

[yousuf khan]

Jose wrote:
> The ntoskrnl.exe will show up as the "Probably caused by" frequently
> but that in itself is generally not the problem.

I agree, actually my main purpose in finding out the root cause of this
is find out if it is caused by hardware rather than software.

I recently added an external USB hard drive to my system, and the
problem started a few days afterward. But there is nothing special about
this external drive, it is just a bog standard drive using the bog
standard Microsoft Mass Storage drivers. And there was a previous bog
standard external drive that is also running on the system which was not
causing a problem.

I'm also looking at the possibility that the problem is caused by the
chipset, an Nvidia Nforce model, which has had nothing but weird issues
with USB devices since I got this motherboard. Ever since I got this
motherboard, I've seen that some devices get recognized as USB 2.0 while
others which should be recognized as USB 2.0 get recognized as USB 1.1.
I've tried the same peripherals on another computer of mine, using an
ATI chipset, and they get recognized properly. So I think the chipset
itself has a faulty implementation of the USB specs.

> If you suspect ntoskrnl.exe, replace it then you will know what it is
> not. If you suspect your other files, replace them too.

In the past when I've had BSODs, it was relatively easy to narrow the
source of the problem down to some third party driver, and update that
driver. But now these are the actual core Windows kernel and related
files, so I am having to do more indepth analysis than I normally would do.

> I would be looking more in the Bugcheck Analysis STACK TEXT section.

I actually previously posted a message on one these newsgroups, where I
posted the summaries of the first three Stop errors I got, but there was
little help that came back. I'll post them again right now (don't have
access to the latest crash summary, since I'm posting this from a
different system).

Yousuf Khan

***
The following are the summaries of each mini-dump:

(1) 31/12/2009 9:27:06 PM
Bug Check String : PAGE_FAULT_IN_NONPAGED_AREA
Bug Check Code : 0x10000050
Parameter 1 : 0x8b55ffaf
Parameter 2 : 0x00000000
Parameter 3 : 0x804f1b2c
Parameter 4 : 0x00000000
Caused By Driver : hal.dll
Caused By Address : hal.dll+2aa8
File Description : Hardware Abstraction Layer DLL

Stack:
hal.dll+2aa8
ntoskrnl.exe+1db2c

(2) 02/01/2010 9:49:05 PM
Bug Check String : BAD_POOL_HEADER
Bug Check Code : 0x00000019
Parameter 1 : 0x00000020
Parameter 2 : 0x8942aab8
Parameter 3 : 0x8942af40
Parameter 4 : 0x8a915628
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+6067a

Stack:
Ntfs.sys+212aa
ntoskrnl.exe+6067a

(3) 06/01/2010 11:22:38 PM
Bug Check String : BAD_POOL_CALLER
Bug Check Code : 0x000000c2
Parameter 1 : 0x00000007
Parameter 2 : 0x00000c3e
Parameter 3 : 0x000027ca
Parameter 4 : 0x8ab31114
Caused By Driver : fltmgr.sys
Caused By Address : fltmgr.sys+14e3f

Stack:
fltmgr.sys+14e3f
hal.dll+2900
ntoskrnl.exe+909b4

[yousuf khan]

Kai Harrekilde-Petersen wrote:
> Are you using ECC-RAM? I've seen 'unexplainable' crashes on an old
> non-ECC machine that was caused by memory corruption. The problem
> increased over time until I replaced the system with an ECC-enabled
> system.
>
> If you don't use ECC, try memtest86 and/or unplugging some of the RAM
> modules.

That was on my list of things to try. Memtest86 is automatically part of
my multi-boot options since I run Ubuntu. However, so far the problem
hasn't really occurred under Ubuntu, just under Windows. Mind you I
don't run Ubuntu long enough on this system to get an adequate idea. The
machine pretty much stays on 24 hours, so it's difficult to take it down
and run a memtest on it for several hours.

Another reason I don't totally suspect it's RAM-related is because the
problems began happening after I installed a new external USB hard drive
to the system. So I'm going to investigate if that contributed to it.

Yousuf Khan

[yousuf khan]

Mark Hobley wrote:
> Yousuf Khan <bbbl67@spammenot.yahoo.com> wrote:
>> The Windows crashes are spaced out 3 or 4 days apart, and I can't run
>> Ubuntu on it for this long to test it. This
>> particular system is a home server, it runs a few background apps that
>> are only available on Windows, so it is limited to running Ubuntu only
>> occasionally, like for example when Windows crashes.
>
> To run a Windows application in Ubuntu:
>
> apt-get install wine


Already have it, and it does run a few apps, which is fine. But not the
one I need it to run (needs access to low-level hardware interfaces).
I've also been looking at getting Virtualbox to run on this thing, but I
don't really have time to get it working at the moment. And regardless,
when you have virtualization, you still need Windows.

Yousuf Khan

[mike]

Yousuf Khan wrote:
> Yousuf Khan wrote:
>> Mark Hobley wrote:
>>> Have you changed something on the system?
>>> Has the harware changed?
>>> Has any software been updated? (Beware of automatic updates)
>>
>> Actually, the only change that I made to the system is that I added a
>> second external USB HD to it. It had a previous USB HD already
>> attached to it before, which is still attached to it, but then I
>> picked up a second one right after Boxing Day. Come to think of it,
>> the first crash occurred just a couple of days after that.
>>
>> I'm willing to entertain the possibility that this new external drive
>> is somehow to blame, but I don't see why. It's just using a standard
>> Microsoft USB Mass Storage driver, and so was the previous external
>> drive. I don't think it could be due to power supply issues as I
>> upgraded the system's power supply early last year to a high-capacity
>> Zalman 650W unit.
>>
>>
>> Yousuf Khan
>
> I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, since
> it's looking like this is becoming storage-related.
>
> First, so to summarize again, I've now had 5 BSOD crashes on one of my
> systems since Christmas. The only change to my system happens to be a
> new external USB hard disk that I got after Christmas. The first crash
> occurred only a few days after attaching this device, on Dec 30th. The
> system previously had a similar external storage enclosure which has had
> no problems. They were similar, however the older drive was a 500GB
> formatted in FAT32, whereas the newer drive is a 1TB formatted in NTFS.
>
> Secondly, the most recent crash occurred right in the middle of a large
> file transfer from one my internal drives to the new external drive.
>
> This is pretty strong circumstantial evidence that something about this
> drive is causing the problem. But I've also been analysing the crash
> dumps, and they all implicate either the OS kernel itself, NTOSKRNL, or
> the hal.dll driver, or the NTFS.SYS driver.
>
> In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) right on
> the NTFS.SYS driver (see quote below):
>
>> BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504}
>>
>> Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 )
>
> So the question is, perhaps USB hard disks formatted to NTFS might not
> respond fast enough to the system's liking, since NTFS usually goes on
> internal hard disks. Is there some way to increase a timeout or anything
> for this drive?
>
> I always wondered why Microsoft bothered to create a new ExFAT file
> system, to replace FAT32, when NTFS was already around. This might be
> the answer.
>
> Yousuf Khan

Don't know if any of this is relevant, but...
I started having file transfer problems when I installed vista.
Network file transfers to/from XP failed randomly, but only when the file
being transferred exceeded ~4MB and was in the middle of a multi-file
transfer. Also seemed to matter which end of the pipe initiated
the transfer.
I couldn't make a vista to vista file transfer fail.

I use totalcommander as my file manager. It has the option to use
file transfer compatibility mode, whatever that is. Doesn't fail in
that mode, so I quit looking for the problem.

I've had usb file transfer failures to external drives when using the
front-mounted ports on my dell.
Hubs are a no-no.
If I look in device manager, I see more entries for root hubs
than for controllers. Don't know exactly what this means, but
sometimes, moving the usb drive to another port helps.

Bus-powered drives are problematic, but I expect your TB drive isn't.
Power supplies that come with external drives are problematic.
Might be worth a look at the PS voltages with a scope under load.

There have been numerous complaints about recent generations of
hard drives in the 1TB range.

NTFS doesn't seem to matter on smaller drives where you can do a
direct ntfs/fat32 comparison on the same hardware.