У меня есть приложение (не написал), который производит дампы APPCRASH в C: \ Windows \ SysWOW64. Приложение во время сброса повреждено, но работает на минимальной мощности, чтобы не потерять данные. Проблема в том, что эти дампы настолько велики, что система тратит большую часть своего времени на их написание, а приложение сильно отстает в обработке и скоро начнет терять данные.
План состоит в том, чтобы либо полностью отключить его, либо установить его на диск ОЗУ и очистить их, как только они попадут на диск ОЗУ.
Теперь я рассмотрел использование этого ключа:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx
Но все, что он делает, теперь генерирует второй дамп вместо перенаправления оригинала.
Свалка называется:
дамп-2013_03_31-15_23_55_772.dmp
Как правило, это сфера деятельности разработчиков под Windows (с такими вещами, как C / C ++), поэтому я бы хотел их поразить, не думая, что ServerFault может дать мне какие-либо ответы на этот вопрос.
Дополнительно: это не циклический дамп файлов (они будут заполнять 20 ГБ, оставшиеся на жестком диске), поэтому я не уверен, является ли это поведением Windows или пользовательским кодом в приложении (если это … ick!).
Чтобы написать DumpFile, приложение должно вызвать функцию «MiniDumpWriteDump», так что это не поведение системы или что-то, что вы можете контролировать, это управляемое приложением. Если он создает дамп при сбоях, он использует «SetUnhandledExceptionFilter», чтобы установить свою собственную процедуру обработки, прежде чем (!) ОС вступит во владение. К сожалению, я не нашел способа переписать этот обработчик из другого процесса, поэтому остается только надеяться, что в приложении есть запись в реестре, переключающая поведение или изменяющая путь (так как мои приложения используют его именно по этой причине ты опиши)
Других решений пока нет …