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