snoopwpf: Snoop 2.9 crashes on startup

Ey, Snoop stays the most awesome WPF inspection tool. It’s not working for me atm, and I missed it the entire day 😉

However, it suddenly stopped working 😦

Problem

When I start Snoop, it doesn’t show up. After a bit of digging, I found out that so-called AppCrash reports are being created (here: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_snoop.exe_37e7083a3a2cc8e51f6b2f47580bbdb1cf5277_00000000_3cb3fea2), and in the Event Log I also found entries about the crashes (see below).

Own steps to fix things

I wasn’t sure if my install was faulty, or maybe something wrong with my installed version, so I uninstalled the one that was installed, and re-installed the latest version, and it still didn’t show up.

Environment

I’m running Windows 10, upgraded to the latest edition. Visual Studio 2017 (latest one 15.8.*), full .NET Framework at least 4.6.2.

Windows Event Entry

Fault bucket 1364462021916346858, type 5
Event Name: CLR20r3
Response: Not available
Cab Id: 0

Problem signature:
P1: snoop.exe
P2: 2.9.0.0
P3: 5b5b9b0b
P4: PresentationCore
P5: 3.0.0.0
P6: 5a7d2bb4
P7: 21db
P8: a
P9: System.NullReferenceException
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF281.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF31E.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF32F.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF35F.tmp.txt

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_snoop.exe_a0bc4fb2736589139e7b5322443942330c8a_00000000_68c6f919

Analysis symbol: 
Rechecking for solution: 0
Report Id: 536d7e93-f7ea-4185-87da-2a9f2ea2164c
Report Status: 268435456
Hashed bucket: 5675642891bd535aa2ef8afacdd5c9ea
Cab Guid: 0

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 19

Most upvoted comments

I don’t believe LoadWindowPlacement is actually relevant to the issue in this case since it also happened when the settings weren’t present on the machine. LoadWindowPlacement seems to just give us an idea of the time frame base don the call stack provided since it happens in OnSourceInitialized which is before the window is activated/shown for the first time.

The actual exception happens within CriticalHandleWMGetobject which has to do with UI Automation and seems to happen in response to the Window placement whether set explicitly by Snoop or not. To better understand what is happening it would still be useful to see the missing frames from the call stack where “[30+ frames]” is present.

Note that I am assuming that the NullReferenceException that you are seeing in the debugger is the same as what was logged in the event viewer. If that isn’t the case, then there may still be something else happening.

If the issue comes back, maybe you want to try to get a memory dump (See What is a dump, and how do I create one? for how to create a dump) when it happens and share it and I can take a look.

On debugging, you may want to try using Visual Studio to launch the Snoop executable (by opening the .exe in Visual Studio) in debug mode with it set to break on on thrown exceptions including Win32 exceptions.

https://github.com/cplotts/snoopwpf/compare/master...tiesmaster:88/investigate?expand=1

Ooooh. Interesting. Maybe we missed something here. I’ll look into this.

Your bad news sounds like good news for you. lol. 😃