Hey again, wow, sorry, it turns out it is actually pretty darn hard to get a debugger attached when you have a single Windows machine. Nothing I can do will allow me to switch users without entirely terminating the session. However, I figured out that despite all of the mayhem, almost shockingly, WER was working correctly. With that knowledge, I flipped on the automatic usermode minidumps and ran into a crash, and sure enough it loaded my dump folder with over a gigabyte of dumps in practically no time (these were full dumps.)
Both for logistic and privacy reasons, I'd prefer to rule out the low-hanging fruit before I send a full dump, but I do have a bunch of them. I loaded a dump of explorer.exe crashing into Visual Studio 2017 rc1 and so far I haven't identified anything that jumps out to me, as a person unfamiliar with how WindowBlinds works. If WindowBlinds is conflicting with another installed piece of software, it's not immediately obvious which.
It looks like the following apps are loading into Explorer.exe's process space:
- Stardock DeskScapes
- Stardock Start10 (+ Shell extension)
- Stardock WindowBlinds (duhh)
- Google Drive Sync
- Adobe Creative Cloud CoreSync
- NVidia drivers (nvwgf2umx.dll, nvapi64.dll)
- Microsoft OneDrive
None of this is particularly shocking. I am guessing the only thing that has probability of coming into play here is the NVidia drivers, but testing that theory would be painful as this is my daily driver. Nonetheless, I'm about to reboot with the drivers disabled to see if that does anything interesting...
I did not notice my Wacom tablet drivers there, which sort-of surprised me. Maybe it's just not on this test user account I'm using, but I would've expected those to be here.
Anyway, here's the full dump of modules: http://pastebin.com/raw/UEvJLy02
I'm no Intel assembly expert, but I am pretty sure that 'add byte ptr [rax],al' is Intel syntax for what translates to '0x00 0x00.' Indeed, I just switched on 'Show Code Bytes' and that's what I'm seeing. Aside from this being nonsensical, I think that confirms we're jumping to the wrong place. What's more interesting is that I do see what appears to be meaningful code just a few bytes away. Maybe what we're seeing is WindowBlinds accidentally missing a jump to some sort of generated code (a trampoline?) - the int 9fh is probably the most fascinating, but I am going to preemptively assume there's some proprietary WindowBlinds stuff going on there that I shouldn't know about.
This is all probably sounding stupid and useless; pardon my utter lack of knowledge in Windows internals and Stardock software. I will keep tweaking variables to see if we can nail down exactly what causes this.