Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Files Filling Up User Profiles RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    When jobs are run as a user, report files seem to be filling up in the following locations:

    c:\users\%username%\appdata\local\Microsoft\Windows\WER\ReportQueue
    c:\users\%username%\appdata\local\temp\

    These files end in .hdmp, .mdmp, and .txt

    Is there a way to stop these files from being generated so that we don't have to keep cleaning them up?
    Tuesday, May 19, 2009 7:44 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi rmag

    These are windows error reporting files ( they are dumpsand minidumps of processes that crashed when running under the user's context ). You can disable them, but it might also be interesting to take a quick look at one of them and see what is being reported

    There's a good blog about WER in general here: http://blogs.msdn.com/wer/archive/2009/03/11/an-overview-of-wer-consent-settings-and-corresponding-ui-behavior.aspx

    Disabling it needs a group policy change:
    run gpedit.msc to open the group policy editor
    browse to computer settings/administrative templates/windows components/windows error reporting.
    On the right hand side there will be a "Disable windows error reporting" setting that you can flip on to disable things altogether

    If you want to take a look at one of the dumps the easiest way to do this is through the windows debuggers:
    1) install the windows debuggers from http://www.microsoft.com/whdc/devtools/debugging/default.mspx
    2) make sure the debugger machine has internet access, and copy one of the .hdmps across to it.
    3) run windbg.exe -z foo.hdmp to open up the dump in the gui debugger
    4) from the command window that comes up type:
       1) .symfix c:\cache   - this fixes up the symbol paths so we can resolve stacks
       2) .reload -f ntdll.dll  - this loads symbols for one of the core os dlls and validates that we can do basic analysis
       3) !analyze -v     - this analyzes the dump and should give root cause analysis including the stack back trace from the crash etc.

    If you do try the debugger route, please let us know if it's our bug :-)

    cheers
    jeff
    Wednesday, May 20, 2009 5:43 AM