Vista Tutorial - Kernel dumps no-go to non-C pagefiles in Vista?

I'm getting BSODs, but at the moment, I'm not asking for troubleshooting tips
with the BSODs, just with the kernel dump files.

What I need to know is: Am I running into an undocumented pagefile / kernel
debugging constraint in Vista?

My pagefile is on the primary HDD, but not on the C partition -- instead
it's on a pagefile-only partition (D). The logic was that it wouldn't eat
precious space in the OS partition. I then disabled the C volume pagefile so
that I wouldn't run into any messy situations that might flummox Vista.

.... So I thought.

I checked for a kernel dump file, and couldn't find one in the C:\Windows\
folder. Nor could I find one on the pagefile partition (D).

When I double-checked that my kernel dump settings were correct, Vista gave
me that annoying prompt:

"If you disable the paging file or set the initial size to less than 200
megabytes and a system error occurs, Windows might not record details that
could help identify the problem. Do you want to continue?"

So, what gives? Do you HAVE to have your pagefile on C if you want to be
sure to get a kernel dump? That's so wrong!

Also, Autocheck / Chkdsk did not run on restart after the BSOD. Don't know
if that's linked to the pagefile, or whether it's linked to the kind of error
I got, which was a KERNEL_DATA_INPAGE_ERROR / NTFS.sys / 0x0000007A BSOD this
time around.

I'm going to run Chkdsk, but I want to report this pagefile glitch, in case
anyone has seen this or can offer advice.

* * *

In case you want the gory details of the BSODs, here is the issue:

I've gotten 3-4 KERNEL_DATA_INPAGE_ERROR / NTFS.sys / 0x0000007A BSODs in
the past month, including two in the past two days, and am trying to figure
out whether its a corrupt pagefile, an MBR virus, bad memory, bad laptop
power distribution, or a bad HDD.

I have not yet run Chkdsk, as I said, but will next.


POWER & MEMORY: My power supply seems OK -- the power has never just
randomly died. And the Disk I/O light was lit-up during the entire duration
of the feeze (until hard power off) so I imagine there's enough juice coming
through.

I tried installing some new RAM lately and had to do a bunch of
troubleshooting on it (before RMAing it), so despite taking the appropriate
anti-static precautions, there's a chance I've fried something.

Memtest currently shows no errors.


HDDs: This is the fishy part.

My ThinkPad laptop has a swappable 2nd PATA HDD bay (with a SATA adapter).

The occasional freezes have begun when I have had a new 2nd SATA HDD (WD
Scorpio Blue 500GB) in the swappable bay alongside the primary HDD (Samsung
HM250JI 250GB). It's never happened when I had my old 2ndary HDD (Hitachi) in.

I should also note that the 2ndary HDD was one I joined some partitions on,
so it's now a 'dynamic disk' -- the first time I've formatted one this way.
(Is a dynamic disk sufficiently stable?)

However, the latest freeze happened when I was saving a file to the primary
HDD, not to the 2ndary HDD. (Again, the I/O light was frozen in the lit
state.) Indeed, I don't recall a freeze when saving to the 2ndary HDD.

SMART diagnostics show no bad sectors on either drive. Today, I'm seeing one
"raw read error" for the primary HDD. (Can't be sure that's new, but I think
it is, and I am now tracking things more carefully.)


PAGEFILE: The latest freezes are occurring when I happened to have a million
tabs open in IE. That was the case yesterday. Today it happened when I
resumed from sleep with a million tabs open and was in the middle of saving a
very small file to the primary HDD. Both times the HDD I/O light was lit up
for the duration of the freeze until I hard powered down.

My pagefile is on the primary HDD, but not on the C partition -- instead
it's on the same HDD, just a different partition. (The logic was that it
wouldn't eat precious space in the OS partition.)


MBR MALWARE: I did a very thorough clean-out (spyware, trojans, viruses,
rootkits) in the wake of the first freeze, but absolutely nothing turned up
that was of concern. Of course, there could be something completely invisible
hiding in the MBR, but it's not a highly likely scenario. I haven't noticed
random network activity.

Yes, the dump data is saved only on the drive that contains %systemroot%,
which is c: on Vista. There are certain technical reasons for this.
Don't remember where this requirement is documented - anyway it is
not new, in fact, it existed in all NT versions.

Regards,
--PA


"a.k.a." <aka@xxxxxx> wrote in message
news:8205A927-D4C4-424A-B545-0450984F470F@xxxxxx

Thanks, Pavel.

Can you check the next thread in this forum? It's stage II of what seems to
be a terminal cancer in the system. Just looking for some kind of vague
diagnosis!

"Pavel A." wrote:

One final question: What if I re-enable the C pagefile?

I want to move most of the pagefile space off of C if at all possible. Say I
give it a 500MB pagefile on C, which should be enough to write any dump file.
Then assume the 500MB fills up, and Windows starts using the second pagefile
space elsewhere. Will Windows happily OVERWRITE the existing pagefile on C at
the next BSOD, and give me a memory dump (which is what I want it to do), or
will Windows assume there's no pagefile space left on which to write a memory
dump?

Further, am I going to get into trouble if I enable TWO different pagefiles
for the same OS? What's Vista's pagefile behavior likely to be?

I ask, because I thought the whole point to putting a pagefile on a
different partition was so that it would speed things up, and even prevent
data allocation conflicts....

Thanks!



"a.k.a." wrote:

For a full kernel dump the pagefil.sys must equal, or exceed, the amount of
RAM installed on the system. The pagefil.sys must also be on the partition
where Vista is running from.

--

Richard Urban
Microsoft MVP
Windows Desktop Experience


"a.k.a." <aka@xxxxxx> wrote in message
news:6E52FC9D-BE26-42B9-8DBB-6B88CB2D80A7@xxxxxx

No, sorry, I don't know Vista this much. Actually, still avoid it and hope
Win7 will be better.
It looks like you've assembled this machine yourself or did a major mod.
If so, I'd advice running the system level HCT tests on it. This is not an
easy procedure, though.
Vista has higher requirements to all parts and quality of assembly than XP


Regards,
--PA


"a.k.a." <aka@xxxxxx> wrote in message
news:A02878B9-A516-4652-82F3-D2BA7A8232C9@xxxxxx