WinDbg: Unable to get verifier list

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

Mark Hobley wrote:
> Yousuf Khan <(E-Mail Removed)> 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

Jose wrote:
> If you are using the small memory dump you will have that message.
>
> You need to adjust your Startup and Recovery Debugging information to
> do a complete memory dump and try again with a new dump file.
>
> Did you get nothing useful from !analyze -v


Okay, I've had another crash, and this time I got a full core dump
saved. It was the following Stop code:

BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504}
Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 )


I can't see anything particularly wrong when I run the Debugger's
"!verifier" command, and get the following output:

> 1: kd> !verifier
>
> Verify Level 9b ... enabled options are:
> Special pool
> Special irql
> All pool allocations checked on unload
> Io subsystem checking enabled
> DMA checking enabled
>
> Summary of All Verifier Statistics
>
> RaiseIrqls 0xd50089c4
> AcquireSpinLocks 0x6f16d5ff
> Synch Executions 0x0
> Trims 0x19e7df6
>
> Pool Allocations Attempted 0x426ff0e3
> Pool Allocations Succeeded 0x426ff0e3
> Pool Allocations Succeeded SpecialPool 0xddd6d41
> Pool Allocations With NO TAG 0x0
> Pool Allocations Failed 0x0
> Resource Allocations Failed Deliberately 0x0
>
> Current paged pool allocations 0x23b7f for 059076CC bytes
> Peak paged pool allocations 0x23b88 for 05910BDC bytes
> Current nonpaged pool allocations 0x29871 for 014AED80 bytes
> Peak nonpaged pool allocations 0x29888 for 014BF6E4 bytes

However, when I run the "!verifier 3" command, I get what looks like an
endless list of not-freed pool allocations. The list just scrolls off
the debugger window and there isn't enough to time or space to capture
them all. Is this normal?

Yousuf Khan

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

Yousuf

See the following
http://support.microsoft.com/kb/314477

--
Peter

Please Reply to Newsgroup for the benefit of others
Requests for assistance by email can not and will not be acknowledged.

"Yousuf Khan" <(E-Mail Removed)> wrote in message news:4b4a4b5e$(E-Mail Removed)...
> 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