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 MALWA 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." wrote in message
...
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 MALWA 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.

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:

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." wrote in message
...
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 MALWA 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.

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:

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 MALWA 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.

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." wrote in message
...
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:

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 MALWA 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.

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." wrote in message
...
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:

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." wrote in message
...
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 MALWA 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.

Hi,

Just a point to note in addition to what others have stated: What you are
doing it counterproductive and can cause excessive disk thrashing if the
system is paging heavily. This will be detrimental to system performance and
can shorten the life of your hard drive considerably. Even casual paging
will likely experience performance delays as the drive head seeks out bits
on differing volumes spanning the drive.

--
Best of Luck,

Rick Rogers, aka "Nutcase" - Microsoft MVP
http://mvp.support.microsoft.com/
Windows help - www.rickrogers.org
My thoughts http://rick-mvp.blogspot.com

"a.k.a." wrote in message
...
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 MALWA 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.

Rick,

The disk thrashing problem is duly noted! As I said, I've got TWO HDDs in
this laptop. The original setup was the pagefile was on the 2nd HDD. No disk
thrashing. Then I discovered the kernel dump problem.

But Richard Urban answered my question: For kernel dump purposes, there's no
point in having a pagefile space smaller than your existing RAM, so there's
no point in splitting it across two drives.

There's honestly a lot of stress out in the Intertubes on putting a pagefile
on a different drive to take weight off the OS' HDD. It wout be nice if MS
were able to engineer a kernel dump to a non-C drive for that reason.

"Rick Rogers" wrote:

Hi,

Just a point to note in addition to what others have stated: What you are
doing it counterproductive and can cause excessive disk thrashing if the
system is paging heavily. This will be detrimental to system performance and
can shorten the life of your hard drive considerably. Even casual paging
will likely experience performance delays as the drive head seeks out bits
on differing volumes spanning the drive.

--
Best of Luck,

Rick Rogers, aka "Nutcase" - Microsoft MVP
http://mvp.support.microsoft.com/
Windows help - www.rickrogers.org
My thoughts http://rick-mvp.blogspot.com

"a.k.a." wrote in message
...
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 MALWA 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.

In message a.k.a.
was claimed to have wrote:

The disk thrashing problem is duly noted! As I said, I've got TWO HDDs in
this laptop. The original setup was the pagefile was on the 2nd HDD. No disk
thrashing. Then I discovered the kernel dump problem.

You didn't mention that, in fact you specifically mentioned the
opposite:

|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 any confusion is somewhat understandable.

But Richard Urban answered my question: For kernel dump purposes, there's no
point in having a pagefile space smaller than your existing RAM, so there's
no point in splitting it across two drives.

That all depends -- If you need a pagefile larger then your RAM, then
definitely split it across multiple drives.

If not, then don't.

Also remember that your hard drives can spin down independently of each
other, so you may actually cut into your battery life by putting the
page file on the second drive vs allowing it to spin down due to
inactivity.

"DevilsPGD" wrote:

The disk thrashing problem is duly noted! As I said, I've got TWO HDDs in
this laptop. The original setup was the pagefile was on the 2nd HDD. No disk
thrashing. Then I discovered the kernel dump problem.

You didn't mention that, in fact you specifically mentioned the
opposite:

Oh! Sorry about the confusion. I'm trying to keep track of several different
threads. CURRENTLY I have the pagefile on a different partition of the same
drive, but THE PLAN (that I'm moving toward as I reconfigure) has always been
getting the pagefile on a different drive.


But Richard Urban answered my question: For kernel dump purposes, there's no
point in having a pagefile space smaller than your existing RAM, so there's
no point in splitting it across two drives.

That all depends -- If you need a pagefile larger then your RAM, then
definitely split it across multiple drives.

If not, then don't.

Also remember that your hard drives can spin down independently of each
other, so you may actually cut into your battery life by putting the
page file on the second drive vs allowing it to spin down due to
inactivity.

Now THAT'S an angle I hadn't considered! Hmm.... I'll definitely keep this
in mind.

MANY THANKS to all of you (Pavel, Richard, Rick and DevilsPGD) for the
insights!

Happy weekend!

a.k.a.