Programdata microsoft windows wer reportarchive

Служба Windows Error Reporting (WER) служит для сбора и отправки отладочной информации о падении системных и сторонних приложений в Windows на сервера Microsoft. По задумке Microsoft, эта информация должна анализироваться и при наличии решения, вариант исправления проблемы должен отправляется пользователю через Windows Error Reporting Response. Но по факту мало кто пользуется этим функционалом, хотя Microsoft настойчиво оставляет службу сбора ошибок WER включенной по умолчанию во всех последних версиях Windows. В большинстве случае о службе WER вспоминают, когда каталог C:\ProgramData\Microsoft\Windows\WER\ReportQueue\ начинает занимать много места на системном диске (вплоть до нескольких десятков Гб), даже не смотря на то что на этом каталоге по умолчанию включена NTFS компрессия.

Картинка с сайта: winitpro.ru

Служба Windows Error Reporting

Служба Windows Error Reporting при появлении ошибки показывает диалоговое окно, предлагающее отправить отчет об ошибке в корпорацию Microsoft. Когда в Windows вы видите сообщение об ошибке
YourApp has stop working
, в это время в служба Windows Error Reporting запускает утилиту WerFault.exe для сбора отладочных данных (могут включать в себя дамп памяти).

Данные пользователя сохраняются в профиль пользователя:

%USERPROFILE%\AppData\Local\Microsoft\Windows\wer

Системные данные – в системный каталог:

%ALLUSERSPROFILE%\Microsoft\Windows\WER\

Служба Windows Error Reporting представляет собой отдельный сервис Windows. Вы можете проверить состояние службы командой PowerShell:

Get-Service WerSvc

Внутри каталога WER\ReportQueue\ содержится множество каталогов, с именами в формате:

• Critical_6.3.9600.18384_{ID}_00000000_cab_3222bf78
• Critical_powershell.exe_{ID}_cab_271e13c0
• Critical_sqlservr.exe__{ID}_cab_b3a19651
• NonCritical_7.9.9600.18235__{ID}_0bfcb07a
• AppCrash_cmd.exe_{ID}_bda769bf_37d3b403

Как вы видите, имя каталога содержит степень критичности события и имя конкретного exe файла, который завершился аварийно. Во всех каталогах обязательно имеется файл Report.wer, который содержит описание ошибок и несколько файлов с дополнительной информацией.

Очистка папки WER\ReportQueue в Windows

Как правило, размер каждой папки в WER незначителен, но в некоторых случаях для проблемного процесса генерируется дамп памяти, который занимает довольно много места. На скриншоте ниже видно, что размер файла дампа memory.hdmp составляет около 610 Мб. Парочка таким дампов – и на диске исчезло несколько свободных гигибайт.

Картинка с сайта: winitpro.ru

Чтобы очистить все эти ошибки и журналы штатными средствами, откройте панель управления и перейдите в раздел ControlPanel -> System and Security -> Security and Maintenance -> Maintenance -> View reliability history -> View all problem reports (Control Panel\System and Security\Security and Maintenance\Problem Reports) и нажмите на кнопку Clear all problem reports.

Картинка с сайта: winitpro.ru

Для быстрого освобождения места на диске от файлов отладки, сгенерированных службой WER, содержимое следующих каталогов можно безболезненно очистить вручную.

• C:\ProgramData\Microsoft\Windows\WER\ReportArchive\
• C:\ProgramData\Microsoft\Windows\WER\ReportQueue\

Следующие команды PowerShell удалят из каталога каталогов WER все файлы, старше 15 дней:

Get-ChildItem -Path  'C:\ProgramData\Microsoft\Windows\WER\ReportArchive' -Recurse | Where-Object CreationTime -lt (Get-Date).AddDays(-15) | Remove-Item -force -Recurse
Get-ChildItem -Path  'C:\ProgramData\Microsoft\Windows\WER\ReportQueue' -Recurse | Where-Object CreationTime -lt (Get-Date).AddDays(-15) | Remove-Item -force –Recurse

Для очистки каталогов WER в пользовательских профилях используйте такой скрипт:

$users = Get-ChildItem c:\users|where{$_.name -notmatch 'Public|default'}
foreach ($user in $users){
Get-ChildItem "C:\Users\$User\AppData\Local\Microsoft\Windows\WER\ " –Recurse -ErrorAction SilentlyContinue | Remove-Item –force –Recurse
}

Отключение Window Error Reporting в Windows Server

В Windows Server 2019/2016/2012R2 вы можете управлять состоянием WER с помощью PowerShell. Вы можете отключить службу Windows Error Reporting:

Get-Service WerSvc| stop-service –passthru -force
Set-Service WerSvc –startuptype manual –passthru

Но есть более корректные способы отключения WER в Windows. В версии PowerShell 4.0 добавлен отдельный модуль WindowsErrorReporting из трех командлетов:

Get-Command -Module WindowsErrorReporting

Картинка с сайта: winitpro.ru

Проверить состояние службы Windows Error Reporting можно командой:

Get-WindowsErrorReporting

Для отключения WER, выполните:

Disable-WindowsErrorReporting

Картинка с сайта: winitpro.ru

В Windows Server 2012 R2 можно отключить запись информации об ошибках Windows Error Reporting через панель управления (Control Panel -> System and Security -> Action Center -> раздел Maintenance -> Settings -> выберите опцию I don’t want to participate, and don’t ask me again

Картинка с сайта: winitpro.ru

Отключаем сбор и отправки отчетов об ошибках в Windows 10

В Windows 10 нельзя отключить Error Reporting через панель управления. В графическогм интерфейсе можно только проверить ее статус (Система и безопасность ->Центр безопасности и обслуживания -> секция Обслуживание). Как вы видите, по умолчанию параметр Поиск решения для указанных в отчетах проблем включен (Control Panel -> System and Security -> Security and Maintenance -> Maintenance -> Report problems = On).

Картинка с сайта: winitpro.ru

HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting нужно создать новый параметр типа DWORD (32 бита) с именем Disabled и значением 1.

Можно отключить сбор ошибок WER для конкретных пользователей:

reg add "HKCU\Software\Microsoft\Windows\Windows Error Reporting" /v "Disabled" /t REG_DWORD /d "1" /f

Или отключить WER для всех:
reg add "HKLM\Software\Microsoft\Windows\Windows Error Reporting" /v "Disabled" /t REG_DWORD /d "1" /f

Картинка с сайта: winitpro.ru

Измените параметр реестра и проверьте статус параметра Поиск решения для указанных в отчетах проблем в панели управления. Его статус должен изменится на Отключено.

Картинка с сайта: winitpro.ru

Отключение Windows Error Reporting через GPO

Также вы можете управлять настройками службы Windows Error Reporting через групповые политики.

Запустите редактор локальной (
gpedit.msc
) или доменной GPO (
gpmc.msc
) и перейдите в ветку реестра Computer Configuration -> Administrative Templates -> Windows Components -> Windows Error Reporting (Компоненты Windows -> Отчеты об ошибках Windows). Для отключения сбора и отправки ошибок через WER включите политику Disable Windows Error Reporting (Отключить отчеты об ошибках Windows).

Аналогичная политика есть в пользовательском разделе политик (User Configuration).

Картинка с сайта: winitpro.ru

Обновите GPO (перезагрузка не потребуется).

В результате в Windows перестанут формироваться сообщения об ошибках Windows и отправляться в Microsoft.

Windows 7 / Getting Started

The ReportArchive folder contains reports that have been uploaded or denied upload (via
policy or explicit user action). This folder is referred to as the Archive store. Reports that are
successfully submitted from the queue store(s) are automatically transferred to the archive store.

You also can create an Event Reporting Console (ERC) folder in the WER store folder(s). The
subfolders in the ERC folder store response metadata and templates used for displaying the
response data in the Problem Reports And Solutions Control Panel. You don’t need to modify
the data in the ERC folder, and modifying the data is not supported. The location of the
ReportArchive folder is either of the following:

• Users\<username>\AppData\Local\Microsoft\Windows\WER\ReportArchive (for reports
  in the user store)
• ProgramData\Microsoft\Windows\WER\ReportArchive (for reports in the computer store)

Queue Reporting

When a new error report is successfully submitted to any of the queues or directly to the
Watson back-end servers, WER enters Queue Reporting mode. In Queue Reporting mode,
WER will prompt you to send the queued report(s) if conditions permit. If conditions are not
optimal for reporting, WER schedules itself to be started when a network connection is established
(SENS) or when the current user logs on the next time (HKCU\Run). This ensures that at
some point in the future when conditions are right for reporting, infrastructure will be able to
show the queued reporting console.

In Queue Reporting mode, WER performs the following checks in the following order:

1. Is the failing process running in an interactive desktop? If not, WerMgr.exe terminates.
   This is necessary because WER dialog boxes should not be shown for noninteractive
   desktops, such as the ones that the service accounts own.
2. Does the current user have reports in her queue, or is the current user an administrator
   and is administrative queuing enabled? If neither of the conditions is true, the current
   user has no reports to report. In this case, WER will ensure that network and logon
   triggers for the current user are removed, and it will exit immediately. If either of the
   conditions is true, WER attempts to prompt you to report entries in the queue.
3. WER sets the network and logon triggers for the current user in case conditions are not
   optimal for reporting at this time.
4. WER checks network access to see if the last reporting time has expired. If either of
   these checks fails, WerMgr.exe terminates.
5. Open the Problem Reports And Solutions Control Panel to prompt you and update the
   last reporting time.

Store Maintenance

By default, the Queue Management System performs maintenance such as deleting stale
data and trimming the size of the queue on a report store whenever 50 saved reports are in
the store. When the total queued report count exceeds the number defined in the registry
value MaxQueueCount or the registry value MaxArchiveCount for archive stores, the queue
subsystem deletes the oldest .cab files from the queues in the following order until the size of
the queue reaches MaxQueueCount or no more CABs remain to delete:

• Archive Store
• Signoff Queue
• Upload Queue

The metadata for a report persists for one calendar year unless the user has disabled the
archive via the DisableArchive setting.

WER queue data retention policies can be configured using Group Policy. If no queuing
policies are configured, the Archive queue will retain 1,000 reports and the Upload/Signoff
queue will retain 50 reports. If a queue becomes full and a new report is created, the new
report will overwrite the oldest report in the respective queue.

Queue Triggers

This section describes the launch triggers that WER uses to ensure that the queued reporting
prompt is started for users when they have unsent reports in their queues. Triggers are
persistent across reboots.

WER launch triggers include:

• Network trigger This trigger starts WerMgr.exe in Queue Reporting mode for a
  specific user when a network connection is established. The network trigger is implemented
  through the SENS API that senses the presence of a network connection.
• Logon trigger This trigger starts WerMgr.exe in Queue Reporting mode for a
  specific user when the user logs on. WerMgr.exe is responsible for WER error queue management.
• Administrator trigger The administrator trigger notifies an administrator of unsent
  entries in the machine queue. This trigger occurs only for administrators on the system.

Are you frustrated by “access denied” errors when trying to open Windows Error Reporting (WER) archives? This guide helps you troubleshoot and modify permissions so you can capture critical crash dump files and resolve server issues.

TOC

Understanding Windows Error Reporting

Windows Error Reporting (WER) is a feature built into the Windows operating system that collects and archives data on application crashes, unhandled exceptions, and kernel-level issues. This data is invaluable to administrators and developers who need to diagnose the root causes of system instabilities. By default, WER stores temporary files in:

C:\ProgramData\Microsoft\Windows\WER\Temp

Before long, these files are moved to a more permanent location:

C:\ProgramData\Microsoft\Windows\WER\ReportArchive

If your application pool crashes repeatedly in a Windows Server environment (including Azure VMs), WER logs and crash dumps may be the key to diagnosing root causes. But retrieving these files can be a challenge when system or domain-level security policies restrict folder access. Let’s examine how WER works and why its archiving process often triggers permission issues.

What Is WER and Why Does It Matter?

WER automatically monitors the operating system and your applications for crash events or unresponsive processes. When a crash occurs, WER does the following:

1. Captures the crash details – Memory dumps, stack traces, error logs, and other debug info.
2. Generates a unique ID – WER associates the crash with a specific application, module, or OS component.
3. Temporarily stores data – Initially in the WER\Temp directory.
4. Archives data – Moves crash dumps and log files to WER\ReportArchive after a short time, preserving them for further analysis.
5. Optionally sends data to Microsoft – Depending on your error reporting settings.

For Windows administrators, these archived crash reports are a goldmine. They can provide explicit error codes and stack information that pinpoint exactly where your application failed. Without them, diagnosing random or intermittent crashes is much more difficult.

Common Scenarios for Accessing WER Data

While many people never touch WER data, you may need direct access to WER\ReportArchive in situations such as:

• Intermittent or rare crashes: Standard event logs don’t provide enough detail.
• Custom application debugging: You need a full memory dump to analyze.
• Vendor support requests: Third-party software providers might request a crash dump.
• Forensic analysis: Investigating serious faults or security-related incidents.

However, opening these folders often fails due to strict access controls, especially on servers that are domain-joined and subject to group policies. The next sections explore why these hurdles exist.

Challenges with the WER\ReportArchive Folder

The WER\ReportArchive folder is protected by default. Windows places tight restrictions on critical system folders to prevent unauthorized users—or malicious software—from tampering with diagnostic data or system configurations. This can be especially noticeable on Windows Server platforms where security is typically stricter than on client operating systems.

Why Access May Be Denied

When you receive an “access denied” error, the root cause usually falls under one or more of the following categories:

1. Ownership: A special system account (like NT AUTHORITY\SYSTEM or TrustedInstaller) might own the folder.
2. Group Policy Restrictions: Domain policies might override manual permission changes, forcing administrators to escalate privileges or coordinate with domain admins.
3. Azure VM Security: In cloud-hosted VMs, custom scripts or roles might hamper full local admin control.
4. File in Use: WER might be actively writing or archiving data, causing locked file handles.

Ownership and Permissions

Even if you are a local Administrator, Windows often treats certain directories as “system-owned.” If the system account or TrustedInstaller has exclusive ownership, you’ll be locked out unless you manually take ownership. After taking ownership, you still need to edit the ACL (Access Control List) to grant your account or group explicit permissions.

Group Policies and Domain Restrictions

In a domain environment, group policies can automatically revert certain folders to default ownership or restrict changes to local Administrators. For example, a security baseline might enforce that system directories remain locked down. If your environment uses custom GPOs, you may need domain-level policy updates to ensure your changes are preserved.

Azure VM Considerations

On Azure VMs, you might assume you have full control by default—but additional roles or marketplace images can come with preconfigured security settings. For instance, Azure’s Security Center or similar services might have protective measures enabled. Even with local administrator privileges, changes can be undone by these configurations. If you suspect an Azure-level policy is interfering, coordinate with your organization’s Azure administrators.

Step-by-Step Guide to Gaining Access

Below are recommended approaches to fixing “access denied” errors and retrieving WER crash dump archives. We’ll begin with the simplest (using the GUI) and move on to more advanced or domain-oriented methods.

Method 1: Changing Ownership via GUI

This method is often the first attempt when you need quick access and have local or domain admin privileges.

1. Open File Explorer and navigate to C:\ProgramData\Microsoft\Windows\WER\ReportArchive.
2. Right-click the folder → Properties → Security → Advanced.
3. In the “Advanced Security Settings” window, change the owner to your admin account:

• Click Change next to Owner.
• Type your username or administrator group name.
• Check the box labeled Replace owner on subcontainers and objects.

1. Close and reopen the properties dialog.
2. Grant Full Control: Back in the folder’s properties, click Edit (or “Change permissions”), then add your account or group with Full control.

If no group policies override your changes, you should now be able to browse ReportArchive, open crash files, and copy them elsewhere.

Method 2: Using Command Prompt Tools

If the GUI approach fails or you’re more comfortable with command-line operations, try takeown and icacls:

1. Launch Command Prompt (or PowerShell) as Administrator.
2. Take ownership recursively:

   takeown /f "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_w3wp.exe_..." /r /d y

The above command forces ownership even if you’re not listed on the ACL.

1. Grant permissions:

   icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_w3wp.exe_..." /grant Administrators:F /t

Here, Administrators is the built-in administrators group. The /t switch applies changes to all subfolders and files.

1. Verify there are no errors. Attempt accessing the folder again in Explorer.

These commands explicitly override ownership and ACLs. However, if group policies are set to revert changes, you might temporarily gain access but could lose it again on the next policy refresh.

Method 3: Reviewing Group Policies

Group Policy Objects (GPOs) play a major role in large organizations. If you’re repeatedly locked out after applying new permissions, investigate local or domain GPOs:

• Run gpedit.msc (Local Group Policy Editor) if you’re not domain-joined. Check under Computer Configuration → Windows Settings → Security Settings → File System or Administrative Templates.
• Check domain-level GPOs via the Group Policy Management Console (if you have domain admin rights).
• Identify conflicting policies. For instance, a policy might set “TrustedInstaller” or “SYSTEM” as the only allowed owner on system folders.

If your domain’s policies hamper local changes, you’ll need to collaborate with the domain admin team to either create an exception or temporarily relax these restrictions.

Method 4: Testing with a Different Admin Account

Sometimes your primary domain or local account is subject to specific security rules, but another admin account might not be. If you have multiple administrator accounts:

1. Log off your current session.
2. Log in as a different account with local admin privileges.
3. Retry opening the ReportArchive folder or applying the ownership changes above.

It’s possible that the domain or local GPO treats these accounts differently. Testing with another account can also confirm if the problem is user-specific or systemwide.

Method 5: Coordinating with Domain Admins

In a managed enterprise environment, domain admins can easily override or fix permission conflicts. If you can’t bypass the “access denied” error:

1. Open a support ticket with your IT or domain admin team.
2. Provide specifics: The exact folder path (C:\ProgramData\Microsoft\Windows\WER\ReportArchive), the error you see, and your attempts to fix it.
3. Request a domain policy review: They can either allow local ownership or provide a group-based policy granting you read/write access for these logs.

Realistically, domain administrators have the final say on your environment’s security configuration. If they deem it safe, they can relax the relevant settings for your server or create a policy exception.

Troubleshooting and Tips

Even after changing ownership and permissions, you might still face issues, either because group policies keep reverting settings or because the files you need are missing. Here are some extra pointers to help you navigate potential roadblocks.

PsExec for System-Level Access

Microsoft’s PsExec utility allows you to run commands under the Local System account. Because the System account often has more privileges than even a standard administrator, it’s a viable workaround:

1. Download PsExec from the Microsoft Sysinternals website.
2. Open Command Prompt as Administrator.
3. Run:

   psexec -s -i cmd.exe

This launches a new command prompt window as the System account.

1. Navigate to the ReportArchive folder and try copying or moving the files to an accessible location.

However, if a domain-level GPO disallows System from altering permissions or if the GPO resets them, this approach might still fail. Use this method with caution, as running processes under the System account can have security implications.

Ensuring the Crash Dumps Are Still Present

WER data is sometimes transient. Even if you gain access, you might find that the crash dump you need is gone. Here’s why:

• Automatic cleanup: Windows may delete older dumps to free space.
• Rebooting: Certain logs or memory dumps are cleared after system restarts.
• Policy-based cleanup: Your IT department might have configured shorter retention periods.

If your crash dumps are missing, check Event Viewer to confirm if WER logs indicated a successful dump creation. Alternatively, see if logs were moved to a different location, or if they have been automatically uploaded to a remote share.

Long-Term Maintenance Strategies

To avoid repeating these headaches whenever you need new crash dumps, consider implementing a few best practices.

Regular Auditing of Permissions

Take inventory of which system folders require ongoing access. If you handle frequent debugging tasks, request that IT or domain admins make a permanent group policy exception for the WER\ReportArchive folder. That way, you don’t have to reapply ownership or permission changes after each policy refresh.

Automating Log Collection

In a production environment, especially if you manage many servers, manual retrieval of crash dumps is tedious. Tools and scripts can automate:

1. Monitoring for new dump files in WER\Temp and WER\ReportArchive.
2. Copying the files to a secure share or an Azure Storage container.
3. Notifying the admin or developer team that new crash logs are available.

Automation ensures that every critical dump is saved in a centralized, easily accessible location without repeatedly tampering with folder permissions.

Conclusion

Accessing and managing the C:\ProgramData\Microsoft\Windows\WER\ReportArchive folder can be challenging on Windows Server—particularly in domain-joined or Azure-hosted environments. By systematically adjusting ownership, verifying group policy settings, and collaborating with domain administrators, you can obtain the crash dumps you need to troubleshoot application pool failures or other system crashes.

Once you’ve secured the necessary permissions, you’ll have full visibility into the archived crash files. This will let you diagnose intermittent issues, collaborate effectively with vendors or support teams, and maintain a healthier Windows environment. Don’t forget to put in place policies or automation to ensure that collecting future WER data remains a smooth process.