BSOD 0x00000019 after shrinking system volume (SSD)

[Simon1957]

Dear Koolkat

I'm relieved to see you are still helping me - thanks.
Yes, a bit of misunderstanding seems to be going on.
I don't think I got the drift of your contribution and I'm not sure I've quite got my situation across to you either.
I agree that Windows is often blamed for stuff that isn't its fault. I happen to be a great fan of Windows 7.
I'm pretty good at keeping things up to date, although I accept there may be an odd driver that has a more recent version that I haven't tracked down.
The BSODs were, rather than occurring during the shrink/create process, a recurrent problem once the new partition was in place. Until I recreate the new partition I don't have a problem and I don't know whether or not I will have a problem when I do. My system was stable before and has been stable after I removed the new partition. The instability prevailed only when the new partition was present. As indicated to GregRocker, I'll update the thread when I've done all that he suggested.
I hope that is more clear?

 

[koolkat77]

I hope that is more clear?

Yes. Indeed.

Just FYI and you don't need to worry about nothing.

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 19, {20, fffffa80196c8000, fffffa80196c8dd0, 4dd0000}

Probably caused by : volsnap.sys ( volsnap!VspFreeBitMap+3d )

Followup: MachineOwner
---------

8: kd> !analyze -v; !sysinfo cpuspeed; !sysinfo SMBIOS; lmtsmn; q
*******************************************************************************
*                                                                             *
*                        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: 0000000000000020, a pool block header size is corrupt.
Arg2: fffffa80196c8000, The pool entry we were looking for within the page.
Arg3: fffffa80196c8dd0, The next pool entry.
Arg4: 0000000004dd0000, (reserved)

Debugging Details:
------------------


BUGCHECK_STR:  0x19_20

POOL_ADDRESS: GetPointerFromAddress: unable to read from fffff80003ab9100
GetUlongFromAddress: unable to read from fffff80003ab91c0
 fffffa80196c8000 Nonpaged pool

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff800039b4cae to fffff80003881c00

STACK_TEXT:  
fffff880`100cbc08 fffff800`039b4cae : 00000000`00000019 00000000`00000020 fffffa80`196c8000 fffffa80`196c8dd0 : nt!KeBugCheckEx
fffff880`100cbc10 fffff880`019b2dfd : fffffa80`171b0c40 fffffa80`171b0c40 fffffa80`6d536f56 fffffa80`00000000 : nt!ExDeferredFreePool+0x12da
fffff880`100cbcc0 fffff880`019e9d05 : 00000000`00d06e00 fffffa80`171b0c40 fffffa80`171b0c40 fffff880`100cbd10 : volsnap!VspFreeBitMap+0x3d
fffff880`100cbcf0 fffff800`03b1fede : fffffa80`00000000 fffffa80`1727d6f0 00000000`00000080 fffffa80`12e08040 : volsnap!VspLazyPreCopyOnWriteWorker+0xf5
fffff880`100cbd40 fffff800`03872906 : fffff880`034f9180 fffffa80`1727d6f0 fffffa80`12e25b50 00000000`a0000003 : nt!PspSystemThreadStartup+0x5a
fffff880`100cbd80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
volsnap!VspFreeBitMap+3d
fffff880`019b2dfd 4c8b5b08        mov     r11,qword ptr [rbx+8]

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  volsnap!VspFreeBitMap+3d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: volsnap

IMAGE_NAME:  volsnap.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce792c8

FAILURE_BUCKET_ID:  X64_0x19_20_volsnap!VspFreeBitMap+3d

BUCKET_ID:  X64_0x19_20_volsnap!VspFreeBitMap+3d

Followup: MachineOwner
---------

What is the volsnap.sys file?

VolSnap.sys can be found in the folder C:\Windows\System32\drivers. It belongs to the Microsoft Windows OS. VolSnap.sys is also known as Volume Shadow Copy Driver.

If the VolSnap.sys file gets corrupted, Windows might not boot.

 

[Simon1957]

Dear All

As promised last night here is an update on the results of my activities this morning:

I created a screenshot from Disk Management prior to shrinking my C: drive - attached
I shrank the C: drive and created a new partition from the space released
I created a screenshot from Disk Management after creating the new partition and volume [R:] - attached
I exercised the system for a while with no BSODs occurring
I executed fsutil dirty set on all volumes
I re-booted with a MemTest+ disk in my optical drive and ran one full pass of the tests - results attached
I re-booted again and chkdsk ran finding/correcting only minor inconsistencies on the C: drive - results attached
I extracted the SMART data from the SSD using the manufacturer's tool - results attached
​

In conclusion it looks like there was a one-off problem with Disk Management during the original shrink/create that corrupted the size of the pool block header causing volsnap to BSOD during periodic shadow copy operations.
Many thanks to all contributors for their inputs - the output from the debugging tool was most insightful so special thanks to KK for that.
I'm not sure we can count the BSOD as solved but as far as I'm concerned the thread can be closed.
Thanks again.

Simon

View attachment 278226

View attachment 278227

View attachment 278228

View attachment 278229

View attachment 278265
​

 

[gregrocker]

Do you mean to have Dynamic Spanning on Disk0? This is intended only to span a partition across multiple HD's. Do you have some other configuration there? It will warn that it is about to convert to Dynamic if you try to force a fifth Primary Partition.

Did you research what Pre-Fail and Old-Age mean in the OCZ SMART readings? It doesn't sound good, so I'd want to know exactly what it means and what to watch for.

 

[Simon1957]

Dear GregRocker

Yes, I did mean to have spanning on. I have 2 of my Raptors in RAID 0 (the ones that are attached to SATA III ports on the MB) and the other 3 are in RAID 0 using Intel Matrix Storage Manager. This way I get a notional increase in performance and with the ability to get better space utilisation. I have a very large (1TB) spanned volume for my video assets and am also to create the best possible sizes for the remaining volumes and I couldn't do that without them being in RAID 0. IMSM is a bit of a nightmare, but after some teething troubles it has been working OK for a good few months.

As for the "type" column I agree it looks alarming, but it just indicates what the SMART attribute is intended to indicate. For health you need to examine the numbers and I assure you that the drive is in excellent shape. It has 99% of its life remaining with zero un-correctable errors.

Thanks for the thought, though.

Simon

 

[gregrocker]

Good news. Looks like you're keeping an eye on everything.

Here are Troubleshooting Steps for Windows 7 which are useful for further monitoring your install.

 

[Simon1957]

Guilty as charged! Perhaps the world needs more Geeks.
That is a good list - thank you - and I am happy to report that I'm already on top of nearly all of the items on it.
As previously explained I'm happy to have (quite) a few things loaded at start-up and I have kept the NVIDIA software running. I don't have performance issues and this way everything works seamlessly albeit with some opportunities for my activities being monitored.
I have a few errors and warning in my logs that I haven't cracked (yet), but I'm sure MS would tell me they were nothing to worry about. I do wish MS would not flag them as errors and then say they aren't anything to worry about .

 

[gregrocker]

You can find out which errors are important by as suggested googling the text and ID numbers to find out how others have dealt with them, or if you even need to bother.

Keeping a bunch of items running at Startup because they might like you better is baseless superstition. We go by what works best in tens of thousands of installs. Even MS doesn't have as much experience with Win7 since they have other things to do, too.

 

[Simon1957]

Thanks again.

As to errors, I do Google them and find that there are many people who share the view that if they're classified as errors then there should be a fix other than just ignoring them because they're actually harmless.
In terms of start-up items I am not saying that you're wrong, I'm just saying I prefer not to trim these down to the bare bones. I don't have performance issues so, in this particular case, I choose to employ the "if it ain't broke, don't fix it" strategy. It may not be "correct", but it is the choice I make.
But all that is, I think, a little off-topic albeit an interesting discussion .