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

Discussion in 'Windows Vista General Discussion' started by Matt Neerincx [MSFT], Jan 7, 2008.

  1. 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?
     
    Matt Neerincx [MSFT], Jan 7, 2008
    #1
    1. Advertisements

  2. Matt Neerincx [MSFT]

    Rick Rogers Guest

    Hi,

    Not seen nor heard of that happening. Any chance you placed limits on the
    virtual memory?
     
    Rick Rogers, Jan 8, 2008
    #2
    1. Advertisements

  3. 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.
     
    Matt Neerincx [MSFT], Jan 8, 2008
    #3
  4. Matt Neerincx [MSFT]

    Rick Rogers Guest

    Hi,

    Have you tried deleting any existing memory.dmp file to see if a new one
    gets created?
     
    Rick Rogers, Jan 9, 2008
    #4
  5. 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.
     
    Matt Neerincx [MSFT], Jan 9, 2008
    #5
  6. Matt Neerincx [MSFT]

    Rick Rogers Guest

    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.



     
    Rick Rogers, Jan 9, 2008
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.