diff --git a/input/posts/keepass-crash.md b/input/posts/keepass-crash.md
new file mode 100644
index 0000000..1d13aca
--- /dev/null
+++ b/input/posts/keepass-crash.md
@@ -0,0 +1,35 @@
+Title: KeePass Random Crashing
+Description: A red herring to the root cause.
+---
+
+A couple months ago I noticed a really annoying problem, multiple times a day, my password manager KeePass would crash. The first thing I enabled was WER (Windows Error Reporting), so that I could gleam some information from the full memory dumps.
+
+KeePass is a managed .NET application (.NET Framework to be specific), so debugging a crash should be relatively easy as all the necessary symbols should exist in the deployed application. But Looking at the dumps, it was immediately obvious that the crash was occurring outside of managed .NET.
+
+Running Visual Studio's memory dump debugger in mixed mode produced the following stack:
+
+```
+MMDevAPI!CDeviceEnumerator::OnPropertyValueChanged+0x1d3
+MMDevAPI!CLocalEndpointEnumerator::OnMediaNotification+0x118
+MMDevAPI!CMediaNotifications::OnMediaNotificationWorkerHandler+0x24e
+ntdll!TppSimplepExecuteCallback+0xa3
+ntdll!TppWorkerThread+0x8f6
+kernel32!BaseThreadInitThunk+0x1d
+ntdll!RtlUserThreadStart+0x28
+```
+
+The exception was:
+
+```
+Access violation reading location 0x0000000000000038
+```
+
+Looking at other .NET threads, nothing managed was really executing - which is kind of odd - is this a rare .NET Framework runtime bug? The module at the top of the stack is `MMDevAPI.dll`, which, with a quick Google search, is a library used by the `Core Audio` subsystem in Windows. Just odd... so this crash of the .NET Framework runtime was being triggered by an audio device change event, and some audio device is a little broken?
+
+Well, I poked around, trying to figure out what could trigger an audio change - the KeePass crash would occur when the system idle'd - which suggested to me a power save feature was kicking in (triggering an audio subsystem change).
+
+It turned out I could reproduce this crash by disconnecting my USB audio DAC (Steel Series headphones). So, the USB bus likely entered some power saving mode (disconnecting my DAC), causing an audio subsystem change, which triggered an event that the .NET Framework runtime was listening for, and while .NET was enumerating audio device, some audio device threw-up. That makes sense, so time to look at all the audio devices loaded and see if any of them have a buggy driver.
+
+The first driver that I suspected was problematic was Steam's remote audio virtual audio device - it has this odd property where the Microphone has both audio and microphone device drivers installed concurrently...
+
+But alas, no, ultimately the problem child was Asus's Sonic Studio drivers. As soon as I deleted the driver/driver package from Windows and rebooted, KeePass wouldn't crash with my original repo-case.