IT プロフェッショナルのための技術情報サイト >
フォーラム ホーム
>
Windows HPC Server Deployment, Management, and Administration
>
Files Filling Up User Profiles
Files Filling Up User Profiles
- 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?
回答
- 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- 回答としてマークDon PatteeMSFT, モデレータ2009年5月22日 18:16
すべての返信
- 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- 回答としてマークDon PatteeMSFT, モデレータ2009年5月22日 18:16
