When jobs are run as a user, report files seem to be filling up in the following locations:<br/><br/>c:\users\%username%\appdata\local\Microsoft\Windows\WER\ReportQueue<br/>c:\users\%username%\appdata\local\temp\<br/><br/>These files end in .hdmp, .mdmp, and .txt<br/><br/>Is there a way to stop these files from being generated so that we don't have to keep cleaning them up?© 2009 Microsoft Corporation. All rights reserved.Fri, 22 May 2009 18:16:53 Z7e80f9a3-31fa-4403-bcf3-7cf0a93f21f1http://social.microsoft.com/Forums/en-US/windowshpcitpros/thread/7e80f9a3-31fa-4403-bcf3-7cf0a93f21f1#7e80f9a3-31fa-4403-bcf3-7cf0a93f21f1http://social.microsoft.com/Forums/en-US/windowshpcitpros/thread/7e80f9a3-31fa-4403-bcf3-7cf0a93f21f1#7e80f9a3-31fa-4403-bcf3-7cf0a93f21f1rmaghttp://social.microsoft.com/Profile/en-US/?user=rmagWhen jobs are run as a user, report files seem to be filling up in the following locations:<br/><br/>c:\users\%username%\appdata\local\Microsoft\Windows\WER\ReportQueue<br/>c:\users\%username%\appdata\local\temp\<br/><br/>These files end in .hdmp, .mdmp, and .txt<br/><br/>Is there a way to stop these files from being generated so that we don't have to keep cleaning them up?Tue, 19 May 2009 19:44:15 Z2009-05-19T19:44:15Zhttp://social.microsoft.com/Forums/en-US/windowshpcitpros/thread/7e80f9a3-31fa-4403-bcf3-7cf0a93f21f1#a119823c-62b5-43fc-a3be-9237d2e3f634http://social.microsoft.com/Forums/en-US/windowshpcitpros/thread/7e80f9a3-31fa-4403-bcf3-7cf0a93f21f1#a119823c-62b5-43fc-a3be-9237d2e3f634Jeff Baxterhttp://social.microsoft.com/Profile/en-US/?user=Jeff%20BaxterHi rmag<br/><br/>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<br/><strong><br/></strong>There's a good blog about WER in general here: <a href="http://blogs.msdn.com/wer/archive/2009/03/11/an-overview-of-wer-consent-settings-and-corresponding-ui-behavior.aspx">http://blogs.msdn.com/wer/archive/2009/03/11/an-overview-of-wer-consent-settings-and-corresponding-ui-behavior.aspx</a><br/><br/>Disabling it needs a group policy change:<br/>run gpedit.msc to open the group policy editor<br/>browse to computer settings/administrative templates/windows components/windows error reporting. <br/>On the right hand side there will be a &quot;Disable windows error reporting&quot; setting that you can flip on to disable things altogether<br/><br/>If you want to take a look at one of the dumps the easiest way to do this is through the windows debuggers:<br/>1) install the windows debuggers from <a href="http://www.microsoft.com/whdc/devtools/debugging/default.mspx">http://www.microsoft.com/whdc/devtools/debugging/default.mspx</a><br/>2) make sure the debugger machine has internet access, and copy one of the .hdmps across to it.<br/>3) run windbg.exe -z foo.hdmp to open up the dump in the gui debugger<br/>4) from the command window that comes up type:<br/>   1) .symfix c:\cache   - this fixes up the symbol paths so we can resolve stacks<br/>   2) .reload -f ntdll.dll  - this loads symbols for one of the core os dlls and validates that we can do basic analysis<br/>   3) !analyze -v     - this analyzes the dump and should give root cause analysis including the stack back trace from the crash etc.<br/><br/>If you do try the debugger route, please let us know if it's our bug :-)<br/><br/>cheers<br/>jeff<br/>Wed, 20 May 2009 05:43:36 Z2009-05-20T05:43:36Z