|
|
Re: Kernel dumps no-go to non-C pagefiles in Vista?
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 Quote:
> 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:
> Quote:
>> 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.
|