WinDbg: Unable to get verifier list

mike wrote:
Arno wrote:
In comp.sys.ibm.pc.hardware.storage mike wrote:
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.

I find this surprising. I have both used long USB cables
(5m) and USB hubs to transfer large volumes of data.
However that was with Linux, it is possible that Windows
vista / 7 has a very low resilience to USB errors. Linux
does up to 4 (I think) retries and bus reset on disk access
errors, whether it is (S)ATA or USB. If vista / 7 fails
the transfer directly after any error, that would explain
the ibserved behaviour. Long cables and USB hubs make
errors more likely.

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.

That means that there are "virual hubs".

Bus-powered drives are problematic, but I expect your TB drive
isn't.

Again, depends. They have a tendency to cause more transfer
errors, but not to unusability, at least not with Linux.

Power supplies that come with external drives are problematic.
Might be worth a look at the PS voltages with a scope under load.

I agree. However I did the scope test with one that caused one
specific drive to have problems and I did see nothing with
a 10MHz 10mV/div (elCheapo, I know) scope. I also played around
a bit with one of these PSUs and it seems some have very little
stability margin.

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

Oh? I have several Samsungs and WDs and no issues. I don't
remember reading more about these or other 1TB drives. Do
you have specifics?

Don't know how you missed it. Back around September,
the press was so bad on Seagate .11 series drives in the 1-1.5TB range
that they were practically giving them away. They had a program
for free data recovery if you sent in your permanently-locked-up
drive. Not clear how many
firmware updates they had. Seems that people were not satisfied
that the firmware fix did anything other than throttle the
performance. Interesting coincidence that they also changed the
warranty from 5-years to, I think, three.
I stayed away from that whole mess.

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

So far the advantage I see for NTFS is extended attributes,
i.e. per user permissions. For a single-user machine and
for external drives this is rather irrelevant.

Doesn't fat32 have a 4GB file size limit?

Yes.

Big problem if you store DVD images

And files created on a PVR etc.

or large backup files on your external drive.

Those arent generally a problem, because the backup apps all allow for that limitation.

Rod Speed wrote:
mike wrote:
Arno wrote:
In comp.sys.ibm.pc.hardware.storage mike wrote:
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.
I find this surprising. I have both used long USB cables
(5m) and USB hubs to transfer large volumes of data.
However that was with Linux, it is possible that Windows
vista / 7 has a very low resilience to USB errors. Linux
does up to 4 (I think) retries and bus reset on disk access
errors, whether it is (S)ATA or USB. If vista / 7 fails
the transfer directly after any error, that would explain
the ibserved behaviour. Long cables and USB hubs make
errors more likely.

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.
That means that there are "virual hubs".

Bus-powered drives are problematic, but I expect your TB drive
isn't.
Again, depends. They have a tendency to cause more transfer
errors, but not to unusability, at least not with Linux.

Power supplies that come with external drives are problematic.
Might be worth a look at the PS voltages with a scope under load.
I agree. However I did the scope test with one that caused one
specific drive to have problems and I did see nothing with
a 10MHz 10mV/div (elCheapo, I know) scope. I also played around
a bit with one of these PSUs and it seems some have very little
stability margin.

There have been numerous complaints about recent generations of
hard drives in the 1TB range.
Oh? I have several Samsungs and WDs and no issues. I don't
remember reading more about these or other 1TB drives. Do
you have specifics?
Don't know how you missed it. Back around September,
the press was so bad on Seagate .11 series drives in the 1-1.5TB range
that they were practically giving them away. They had a program
for free data recovery if you sent in your permanently-locked-up
drive. Not clear how many
firmware updates they had. Seems that people were not satisfied
that the firmware fix did anything other than throttle the
performance. Interesting coincidence that they also changed the
warranty from 5-years to, I think, three.
I stayed away from that whole mess.
NTFS doesn't seem to matter on smaller drives where you can do a
direct ntfs/fat32 comparison on the same hardware.
So far the advantage I see for NTFS is extended attributes,
i.e. per user permissions. For a single-user machine and
for external drives this is rather irrelevant.

Doesn't fat32 have a 4GB file size limit?

Yes.

Big problem if you store DVD images

And files created on a PVR etc.

or large backup files on your external drive.

Those arent generally a problem, because the backup apps all allow for that limitation.


Yes, but if you made the backup to an ntfs drive and tried to copy it to
the external drive, you have a problem. Allowing for a limitation works
great if you know about that limitation beforehand and plan for it.

On Jan 12, 10:52*am, Yousuf Khan wrote:

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.

I have two huge NTFS-formatted USB drives running under Windows, but
Vista, not XP. Never had a BSOD other than due to a video driver, now
fixed.

Robert.

In comp.sys.ibm.pc.hardware.storage mike wrote:
Arno wrote:
[...]
There have been numerous complaints about recent generations of
hard drives in the 1TB range.

Oh? I have several Samsungs and WDs and no issues. I don't
remember reading more about these or other 1TB drives. Do
you have specifics?

Don't know how you missed it. Back around September,
the press was so bad on Seagate .11 series drives in the 1-1.5TB range
that they were practically giving them away. They had a program
for free data recovery if you sent in your permanently-locked-up drive.

Ah, that. But that was a firmware issue and well understood, not
bad drive quality.

Not clear how many
firmware updates they had. Seems that people were not satisfied
that the firmware fix did anything other than throttle the performance.
Interesting coincidence that they also changed the warranty from 5-years
to, I think, three.
I stayed away from that whole mess.

Well, yes, Seagate currently is the one to tay away from.


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

So far the advantage I see for NTFS is extended attributes,
i.e. per user permissions. For a single-user machine and
for external drives this is rather irrelevant.

Doesn't fat32 have a 4GB file size limit? Big problem if
you store DVD images or large backup files on your external drive.

FAT32 has this limit, but a lot of software can work
around it. Or use Linux for backups and images in the
first place. That is what I do, the substandard MS trash
is restriced to things that will only work there with me.
Mostly games.

Arno

--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
mike wrote:
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.

Weird. There's apparently a new networking paradigm with Vista and 7
than there was for XP. You need to enable some kind of compatibility
mode to make it work with XP.

I've had usb file transfer failures to external drives when using the
front-mounted ports on my dell.
Hubs are a no-no.

Good point, I just plugged the drives into whatever free ports were
available at the time without much thought.

And that is what normaly should do. Seems MS screwed up here
somewhere and has far too little resilience in their USB stack.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

Arno wrote:
In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
mike wrote:
I've had usb file transfer failures to external drives when using the
front-mounted ports on my dell.
Hubs are a no-no.

Good point, I just plugged the drives into whatever free ports were
available at the time without much thought.

And that is what normaly should do. Seems MS screwed up here
somewhere and has far too little resilience in their USB stack.

Arno

Well, I reran the file transfer that I was running just before the last
crash. The drives have been rearranged on the USB chain. It went through
properly this time. Not really a scientific observation, but anecdotal.
We'll see if the system stabilizes after a few more days pass.

Yousuf Khan

On Jan 13, 8:47*am, Yousuf Khan wrote:
Arno wrote:
In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
mike wrote:
I've had usb file transfer failures to external drives when using the
front-mounted ports on my dell.
Hubs are a no-no.

Good point, I just plugged the drives into whatever free ports were
available at the time without much thought.

And that is what normaly should do. Seems MS screwed up here
somewhere and has far too little resilience in their USB stack.

Arno

Well, I reran the file transfer that I was running just before the last
crash. The drives have been rearranged on the USB chain. It went through
properly this time. Not really a scientific observation, but anecdotal.
We'll see if the system stabilizes after a few more days pass.

* * * * Yousuf Khan

Sorry I have no useful ideas, but it sounds like you are zeroing in on
it.

In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
Arno wrote:
In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
mike wrote:
I've had usb file transfer failures to external drives when using the
front-mounted ports on my dell.
Hubs are a no-no.

Good point, I just plugged the drives into whatever free ports were
available at the time without much thought.

And that is what normaly should do. Seems MS screwed up here
somewhere and has far too little resilience in their USB stack.

Arno

Well, I reran the file transfer that I was running just before the last
crash. The drives have been rearranged on the USB chain. It went through
properly this time. Not really a scientific observation, but anecdotal.
We'll see if the system stabilizes after a few more days pass.

Sounds good to me. Let us know. I have had to take USB ports out
of service in the past as well, but that was on an ASUS board
where they had insufficient cooling on the southbridge, and
it was not really a surprise to me that portst started giving
up after about 2 years. No more ASUS for me, they are more
expensive and their engineering sucks badly lately.

As to the damaged port, it would still support a mouse or the
like, but filetransfers resulted in device disconnects under
Linux, a bit like your situation. Incidentially, this problem
also affected the SATA port with the same number, I guess they
were arranged in SATA/USB pairs on the chip.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

Arno wrote:
In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
Arno wrote:
In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
mike wrote:
I've had usb file transfer failures to external drives when using the
front-mounted ports on my dell.
Hubs are a no-no.
Good point, I just plugged the drives into whatever free ports were
available at the time without much thought.
And that is what normaly should do. Seems MS screwed up here
somewhere and has far too little resilience in their USB stack.

Arno

Well, I reran the file transfer that I was running just before the last
crash. The drives have been rearranged on the USB chain. It went through
properly this time. Not really a scientific observation, but anecdotal.
We'll see if the system stabilizes after a few more days pass.

Sounds good to me. Let us know. I have had to take USB ports out
of service in the past as well, but that was on an ASUS board
where they had insufficient cooling on the southbridge, and
it was not really a surprise to me that portst started giving
up after about 2 years. No more ASUS for me, they are more
expensive and their engineering sucks badly lately.

As to the damaged port, it would still support a mouse or the
like, but filetransfers resulted in device disconnects under
Linux, a bit like your situation. Incidentially, this problem
also affected the SATA port with the same number, I guess they
were arranged in SATA/USB pairs on the chip.

Arno
Probably doesn't apply in this situation, but if the port is powering
a high power device, like a bus-powered external disk, the current limit
can fail. Some are active current limits, others are PTC resettable
fuses. If you believe the spec on a PTC "fuse", the series resistance
goes up substantially the first time it "blows".
That makes it run hotter, so takes less current to "blow".

Arno wrote:
In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
Well, I reran the file transfer that I was running just before the last
crash. The drives have been rearranged on the USB chain. It went through
properly this time. Not really a scientific observation, but anecdotal.
We'll see if the system stabilizes after a few more days pass.

Crap, spoke too soon! Although that particular file transfer did go
through properly this time, but the system did have another BSOD later
in the day. This time it was a Stop 0xCD
PAGE_FAULT_BEYOND_END_OF_ALLOCATION. According to this Microsoft KB
about Windows Server 2003, but probably applicable to XP as well, it was
due to a delayed write error.

Error message when a Delayed Write Failure event is reported in Windows
Server 2003: "Stop 0x00000019 - BAD_POOL_HEADER" or "Stop 0xCD
PAGE_FAULT_BEYOND_END_OF_ALLOCATION"
"This problem occurs because a certain driver returns an empty device
name to the operating system when a Delayed Write Failure event is
reported."
http://support.microsoft.com/kb/925259

Now during this entire period, I've seen both the Stop 0x19
BAD_POOL_HEADER and now the Stop 0xCD messages at various times, as well
as other Stop messages.

Sounds good to me. Let us know. I have had to take USB ports out
of service in the past as well, but that was on an ASUS board
where they had insufficient cooling on the southbridge, and
it was not really a surprise to me that portst started giving
up after about 2 years. No more ASUS for me, they are more
expensive and their engineering sucks badly lately.

I don't know who's more to blame here, Asus or Nvidia. I've had it upto
here with both. Most of Asus' AMD motherboards used to use Nvidia
chipsets. And most of the computer stores around here only sell Asus
motherboards for some reason, whether Intel or AMD.

As to the damaged port, it would still support a mouse or the
like, but filetransfers resulted in device disconnects under
Linux, a bit like your situation. Incidentially, this problem
also affected the SATA port with the same number, I guess they
were arranged in SATA/USB pairs on the chip.


Is there any utility which will monitor USB disconnects? I don't seem to
see them in the Windows System logs.

Yousuf Khan