Vista - Ctrl-ScrollLock Blue Screen Dump No Longer Generates Memory.Dmp fi

I've been using Ctrl-Scroll Lock Scroll Lock feature (CrashOnCtrlScroll) with
Vista to manually blue screen my machine to capture kernel memory dumps for
debugging purposes when my Vista box hangs. For some reason all of a sudden
this no longer works. The blue screen occurs every time but no memory.dmp
file is generated. I have only one drive in the machine (C: drive) and there
is plenty of free space (12GB).

Any ideas why Vista would stop capturing dump files in this manner? Is
there some limit where it will stop capturing them?

Hi,

Not seen nor heard of that happening. Any chance you placed limits on the
virtual memory?

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

"Matt Neerincx [MSFT]" <MattNeerincxMSFT@xxxxxx> wrote in
message news:A7AC0F4A-2640-4AB1-A213-BE6748DCC15D@xxxxxx

I didn't change anything. After the dumps stopped working I bumped up my
page file to 4GB (I have 2GB RAM) after I read some KB about this but the
dumps no longer work (Kernel dumps). Note I'm doing kernel and not full
memory dumps. I think mini dumps still work.

"Rick Rogers" wrote:

Hi,

Have you tried deleting any existing memory.dmp file to see if a new one
gets created?

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

"Matt Neerincx [MSFT]" <MattNeerincxMSFT@xxxxxx> wrote in
message news:F1E4747F-ED2B-47AB-AFCE-E2ED3048D4A4@xxxxxx

Yes. This is what bit me in the first place!

Normally when you dump the machine, the memory.dmp is automatically
over-written by the new one. For a while I was copying the memory.dmp files
off to a different machine and NOT deleting the old memory.dmp. Later on I
noticed that the memory.dmp for a period of several weeks never changed (it
was the same file). It was then that I realized that dumping was no longer
working. First thing I tried was deleting the memory.dmp file and testing,
still did not work.

Then I found the KB that indicates you need 2x amount of RAM for pagefile, I
set pagefile to 4GB to see if this would help, did not help.

So at this point I suspect there is some counter in Windows that just stops
gathering dumps after a certain number are hit. I need to reset this counter
somehow. I have a bug opened with the Windows folks and they are going to
investigate this. But since many customers out there certainly use this
feature I thought I would ping the world to see if anyone else had hit this
and how to resolve it.

Unfortunately the box I'm debugging is a Lenovo T60P laptop with no COM port
so I cannot kernel debug directly. I sent off for a replacement bay that has
a built-in COM port but this set me back 70$, once I have this I can kernel
debug directly and no longer need the dumps but I like having the dump
feature enabled in case the machine hangs I can capture state. Thanks for
all your help thus far if you have any other suggestions I can try them out.



"Rick Rogers" wrote:

Hi Matt,

I've never heard of any counter that would limit the number of dumps, but
I've never forced a system to dump repeatedly such as you describe either. I
would first try altering the dump path (perhaps a write permissions issue?),
and failing that the only other thought I have is to check event logs. The
system log may not be set to overwrite when full, and could be preventing
completion of the dump process.

I'd be curious to know if the Windows team has a resolution for you and what
it is.

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

"Matt Neerincx [MSFT]" <MattNeerincxMSFT@xxxxxx> wrote in
message news:AD6B703D-1B23-4038-AC68-D4DE97973CC8@xxxxxx