I've encountered a reproducible issue with the Grammarly for Microsoft Outlook desktop add-in following the installation of the Windows 11 23H2 update (KB5032190). The application consistently fails to initialize, resulting in a crash dialog or silent failure upon launching Outlook. Given my focus on system stability and observability, I've conducted a preliminary root cause analysis.
**Environment & Reproduction Steps:**
* **OS:** Windows 11 Pro 23H2, Build 22631.2715
* **Grammarly Version:** 1.2.45.0 (Desktop)
* **Outlook Version:** Microsoft 365 Apps for enterprise, Version 2311 (Build 17029.20028)
* **Reproduction:** Launch Outlook with the Grammarly add-in enabled. The crash occurs during the Grammarly initialization phase, before the Outlook UI is fully loaded.
**Investigation & Logs:**
I've examined the Windows Event Viewer for application crashes. The primary error signature points to a faulting module within the Grammarly executable, often accompanied by an access violation (Exception code: 0xc0000005). This strongly suggests a compatibility issue with a system library or security policy changed by the Windows update.
```
Faulting application name: GrammarlyForOutlook.exe, version: 1.2.45.0, timestamp: 0x652a1b1f
Faulting module name: ntdll.dll, version: 10.0.22621.2506, timestamp: 0x2a6f7143
Exception code: 0xc0000005
Fault offset: 0x0000000000065b30
```
**Actions Taken (Without Success):**
1. Performed a standard repair installation of the Grammarly desktop client.
2. Disabled and re-enabled the add-in within Outlook (`File > Options > Add-ins`).
3. Tested with Windows Defender Antivirus real-time protection temporarily disabled to rule out interference.
4. Clean-booted Windows to eliminate third-party service conflicts.
The persistence of the issue across these steps indicates a deeper integration layer problem. I am interested in whether this is an isolated incident or a broader pattern. Has anyone else performing similar Windows updates encountered this? Furthermore, I am seeking guidance on obtaining more granular diagnostic logs from the Grammarly application itself, akin to enabling debug mode in a daemon, to pinpoint the exact API or system call failure.
Temporary workarounds like using the Grammarly browser extension for Outlook on the web are feasible but suboptimal for desktop workflow integration. A long-term fix likely requires an updated binary from Grammarly's development team addressing the new system constraints.
—Chris
Data over dogma
The faulting module signature and 0xc0000005 exception you've identified are classic indicators of a memory access violation. This often stems from an add-in trying to call a deprecated API or a system DLL that had its memory protection altered by the security updates bundled in that KB.
Before you go down the reinstallation path, check the Grammarly service's dependency behavior. The update may have changed the load order or integrity level of a critical component like the Visual C++ redistributable Grammarly depends on. A quick validation is to run Outlook in safe mode (`outlook.exe /safe`) and see if the add-in loads. If it does, the conflict is likely with another COM add-in that now initializes differently post-update.
Grammarly's support will probably tell you to clear your COM add-ins registry key, but that's a nuclear option. First, try explicitly re-registering the Grammarly DLL from an elevated command prompt. Navigate to its install directory (usually `%LocalAppData%GrammarlyDesktopIntegrations`) and run `regsvr32 GrammarlyForOutlook.dll`. A failure there isolates it to a permissions or dependency issue rather than Outlook itself.
Every dollar counts.
The faulting module detail you found in Event Viewer is the key. An 0xc0000005 in the Grammarly executable itself, not a system DLL, points to a self-inflicted issue that the update merely exposed.
When you have a moment, check the Grammarly desktop app's own update channel. I've seen similar crashes where the core Grammarly service updated to a new runtime, but the Outlook COM add-in bridge remained on an older, incompatible version. The Windows update likely reset some registry permissions or changed the DEP policy for that process space, making a latent bug suddenly fatal.
A clean reinstall often fails because the installer doesn't fully purge the COM registration. Before trying that, manually clear the add-in's registry keys from `HKEY_CURRENT_USERSoftwareMicrosoftOfficeOutlookAddins` and `HKEY_LOCAL_MACHINE...Addins` (if applicable). Then run the Grammarly installer with administrative privileges, but choose the 'Repair' option if available. This forces a fresh registration of the COM components, which is usually what breaks after a major system update.
null
That's a good point about the update exposing a latent bug. I had something similar happen with a different add-in after a Windows update last year.
I'm a bit wary of editing the registry directly, though. Does deleting those keys ever cause Outlook itself to have issues, or is it generally safe as long as you're only removing the specific Grammarly entries?