**Severity:** the simulator's own crash is a nuisance; the consequence is not.
Twice now it has taken the whole machine down without warning, mid-work.
## Summary
`simulator.exe` (Connect IQ SDK 9.2.0) crashes frequently and, in a small
number of cases, the Windows Error Reporting handling of that crash is
followed ~10 seconds later by a crash of `lsass.exe` inside `RPCRT4.dll`.
Windows treats an lsass failure as fatal and force-restarts the machine.
Two occurrences so far, both with the same 9-10 second signature.
## Environment
| SDK | `connectiq-sdk-win-9.2.0-2026-06-09-92a1605b2` |
| Path | `%APPDATA%\Garmin\ConnectIQ\Sdks\connectiq-sdk-win-9.2.0-2026-06-09-92a1605b2\bin\simulator.exe` |
| OS | Windows 11 Pro 25H2, build 26200, 64-bit |
| Usage | automated CI-style runs: repeated app load/unload, device switching, simulator restarts between passes |
## The crash itself
1370 `Application Error` events for `simulator.exe` between 2026-01-07 and
2026-08-27. They are not scattered across the binary - they concentrate
overwhelmingly in one place:
| count | fault offset |
| **1107** | `0x0090a250` |
| 101 | `0x0090a336` |
| 72 | `0x008d628b` |
| 49 | `0x0008d73c` |
| 36 | `0x004aec80` |
| 5 | others |
81% at a single offset, ~88% within two adjacent ones. Exception code is
`0xc0000005` (access violation) in every case, with the faulting module
being `simulator.exe` itself.
Verbatim, the most recent event:
```
Faulting application name: simulator.exe, version: 0.0.0.0, time stamp: 0x6a281e27
Faulting module name: simulator.exe, version: 0.0.0.0, time stamp: 0x6a281e27
Exception code: 0xc0000005
Fault offset: 0x0090a250
Faulting process id: 0x4C04
Faulting application start time: 0x1DD3621DBE6BDE9
Faulting application path: C:\Users\...\connectiq-sdk-win-9.2.0-2026-06-09-92a1605b2\bin\simulator.exe
Faulting module path: (same)
Report Id: 73d6ce5a-53b8-4de0-ab5d-7433c252504b
```
## The consequence
`lsass.exe` has crashed exactly **twice** in the entire Application log, and
both times it followed a `simulator.exe` crash within 10 seconds:
| date | simulator.exe crash | lsass.exe crash | gap |
| 2026-08-13 | 01:47:52 | 01:48:02 | 10 s |
| 2026-08-27 | 14:50:16 | 14:50:26 | 9 s |
Both lsass faults are in `RPCRT4.dll` (different offsets and DLL versions,
so this is not one fixed lsass bug):
```
2026-08-27 14:50:26 RPCRT4.dll 10.0.26100.9168 fault offset 0x000000000001975b
2026-08-13 01:48:02 RPCRT4.dll 10.0.26100.8875 fault offset 0x00000000000516fb
```
Followed immediately by:
```
Wininit 1015: A critical system process, lsass.exe, failed with status
code c0000005. The machine must now be restarted.
System 1074: wininit.exe initiated the restart
```
No bugcheck (Event 1001), no Kernel-Power 41, no WHEA hardware errors - this
is not a BSOD or a power event. It is a clean, forced restart triggered by
the lsass failure.
## Why we believe the two are causally linked, not coincidental
`simulator.exe` crashed 1370 times in the log window. If we count a
15-second window after each crash, those windows cover about **0.42%** of
the elapsed time. For both of the only two lsass crashes in the entire log
to land inside such a window by chance is roughly **1 in 57 000**.
The plausible path: WerFault processes the simulator's crash, makes an RPC
call into lsass as part of that work, and lsass faults inside `RPCRT4.dll`.
Rare - twice in 1370 crashes - but when it happens the machine goes down
without a prompt.
## What we would like
1. **The crash at `0x0090a250`.** 81% of 1370 crashes in one function is a
single defect, and fixing it removes the trigger entirely. We are happy
to run a debug build, capture a full dump, or reproduce on request.
2. **Confirmation of the lsass path**, if Garmin can reproduce it - the
cascade is the part that costs a machine restart rather than a restarted
simulator.
## What we can supply
- Full `.wer` / crash dumps for the `0x0090a250` case
- The exact automation that drives the simulator (app load/unload cycles,
device switching, forced restarts between passes)
- Event log exports for both cascade events
## Workaround in place on our side
We have excluded `simulator.exe` from Windows Error Reporting
(`HKCU\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ExcludedApplications`,
DWORD `simulator.exe = 1`). WerFault no longer handles the crash, so the RPC
call into lsass is not made. The simulator still crashes; the machine no
longer restarts.
This is a mitigation of the consequence only - the crash itself is unchanged.
