This project has moved and is read-only. For the latest updates, please go here.

Error snooping (some) apps on a Group Policy restricted Windows 8 Environment

Jun 7, 2013 at 7:02 AM
Edited Jun 11, 2013 at 3:07 AM
I receive an error while Snoop tries to attach to a running WPF app. The app platform target is Any CPU, running on Windows 8. I'm pretty sure this used to work so I'm at a loss at what has gone wrong.

Error message follows:
There was an error snooping! Message = The type initializer for 'System.Management.Automation.SessionStateScope' threw an exception.

Stack Trace:
   at System.Management.Automation.SessionStateScope.AddSessionStateScopeDefaultVariables()

   at System.Management.Automation.SessionStateScope.GetPrivateVariables()

   at System.Management.Automation.SessionStateScope.SetVariable(String name, Object value, Boolean asValue, Boolean force, SessionStateInternal sessionState, CommandOrigin origin, Boolean fastPath)

   at System.Management.Automation.SessionStateInternal.InitializeSessionStateInternalSpecialVariables(Boolean clearVariablesTable)

   at System.Management.Automation.SessionStateInternal..ctor(SessionStateInternal parent, Boolean linkToGlobal, ExecutionContext context)

   at System.Management.Automation.ExecutionContext.InitializeCommon(AutomationEngine engine, PSHost hostInterface)

   at System.Management.Automation.ExecutionContext..ctor(AutomationEngine engine, PSHost hostInterface, InitialSessionState initialSessionState)

   at System.Management.Automation.AutomationEngine..ctor(PSHost hostInterface, RunspaceConfiguration runspaceConfiguration, InitialSessionState iss)

   at System.Management.Automation.Runspaces.LocalRunspace.DoOpenHelper()

   at System.Management.Automation.Runspaces.LocalRunspace.OpenHelper(Boolean syncCall)

   at System.Management.Automation.Runspaces.RunspaceBase.CoreOpen(Boolean syncCall)

   at System.Management.Automation.Runspaces.RunspaceBase.Open()

   at Snoop.Shell.EmbeddedShellView..ctor()

   at Snoop.SnoopUI.InitShell()

   at Snoop.SnoopUI..ctor()

   at Snoop.SnoopUI.SnoopApplication()

   at Snoop.SnoopUI.GoBabyGo()
Jun 9, 2013 at 9:22 PM
Do the previous versions of snoop work? And does this happen for only certain apps?

If possible, repro apps are extremely helpful at troubleshooting these issues.
Jun 10, 2013 at 3:11 AM
I've been using 2.8 since it came out. If I can I'll try installing a previous version to test it on, but it's quite difficult as it's on a version of Windows 8 locked down severely by group policy.

Other apps are able to be snooped just fine. The app with the issue is a large internal enterprise app which I can't provide for testing unfortunately.

Interestingly, the app with this issue works completely fine when it's run via click-once. I only experience the problem when I run the app from Visual Studio (using F5 and SHIFT + F5).

I wonder if the issue is with the snoop settings. I'll try clearing those out and see how it goes.
Jun 10, 2013 at 4:13 AM
Edited Jun 10, 2013 at 4:17 AM
Removing the settings file had no effect.

I was able to use 2.8 on a previous branch of the same application. In the new branch, the main change was an update from .NET 3.5 to .NET 4. As I said previously, I'm also running on Windows 8 (64 bit) with an AnyCPU target.

I was able to uninstall 2.8 and install 2.71. 2.71 can snoop the application through Visual Studio without any problem.

I uninstalled 2.71 and reinstalled 2.8, but the problem was still there.

I've gone back to 2.71 for the time being so I can continue work. I'd like to resolve the problem though, so let me know if there's anything else you'd like me to try.
Jun 10, 2013 at 4:24 AM
Sorry about the inconvenience. From the stack trace, it looks like it's having issues initializing the PowerShell.

See if these steps help:
1) Get the latest source code from GitHub.
2) In the SnoopUI constructor, comment out a call to the InitShell(); method.
3) Try Snooping.
4) If that works, see if a try-catch over that method will work. You won't have the PowerShell, but at least you'll be able to Snoop.

It looks as though there's a conflict between the way your app loads a certain component, and the way Snoop does. I'm curious if this will enable you to start Snooping again using version 2.8.
Jun 10, 2013 at 5:17 AM
It doesn't seem get that far. As soon as I try to snoop my application, I get an application crash. This is even when the InitShell(); line is commented out.

I tried running it against a working application to figure out how Snoop starts up (to see if I can help diagnose). I can't seem to hit a breakpoint past where the Process.Start is called in Injector.Launch(), so I can't find where the crash is happening.
Jun 10, 2013 at 7:43 AM
Remove references to the assembly "System.Management.Automation", and see what happens. Comment out the Snoop code that depends on this (again, this is just an experimental troubleshooting step, and not proven).
Jun 10, 2013 at 7:59 AM
Also, I do not know if you're aware about this, but Snoop runs inside the application being snooped. In other words, when Snoop "attaches", it programatically injects the Snoop.exe assemblies into the process being Snooped. Therefore, when debugging Snoop, you need to open the Snoop files and put break points in the Visual Studio instance that is debugging your application being Snooped (and not the one debugging Snoop).

I hope this makes sense...
Jun 10, 2013 at 9:10 AM
I removed the automation references and commented out the broken code (-lots- of broken code), but I still get the application crash.

Using your tips I managed to attach VS containing the Snoop source to a running instance of the app I want to snoop and put a debug point in GoBabyGo(). On apps I can snoop, this seems to be the earliest point at which I can break the code following injection. However, on the app I have a problem with, it doesn't get this far.

I can only suggest the injection is failing.

Is there any logging or system events I can look at that can help?
Jun 10, 2013 at 6:25 PM
It looks as though the injection is happening when looking at the call stack. The SnoopUI runs inside the application being snooped. It's the Snooped application that crashes after trying to snoop it, right? That means that the injection probably worked fine.

When rebuilding Snoop, open the SnoopUI.xaml.cs file in the Visual Studio instance that is debugging your application (NOT in the Visual Studio that's debugging Snoop). If you put a breakpoint in the constructor, you should be able to debug and step through.

It's very strange that after commenting out InitShell, it still crashes. If you look at the call stack you posted, that's where it crashes in the constructor.

There are some troubleshooting instructions that we posted for the injection process. See if those help...
Jun 11, 2013 at 3:02 AM
Just so we're clear, I'm getting a different error when running with the Snoop source code to the stack trace at the top. I get a Win8 "Application has stopped working" error with the following detail:
Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: Shell.exe
  Application Version:
  Application Timestamp:    51b12699
  Fault Module Name:    KERNELBASE.dll
  Fault Module Version: 6.2.9200.16451
  Fault Module Timestamp:   50988950
  Exception Code:   c000041d
  Exception Offset: 00014b32
  OS Version:   6.2.9200.
  Locale ID:    3081
  Additional Information 1: e4bc
  Additional Information 2: e4bc4ba9396fd7b1319b80f4044aea05
  Additional Information 3: 4087
  Additional Information 4: 408714a495f8568bbfd9e2d7c6086e06

Read our privacy statement online:

If the online privacy statement is not available, please read our privacy statement offline:
I'm using a slightly different technique to debug as you describe, but it's essentially the same thing:
  • Start my application (Shell.exe) from Visual Studio using CTRL + F5 (so the debugger isn't attached)
  • In the running SnoopOnly solution, Debug | Attach to process Shell.exe to attach the debugger with full Snoop source code
  • Drag the Snoop cross hairs over Shell.exe
I have a break point on the first line of the SnoopUI.xaml.cs constuctor, but it doesn't get that far.

Using other breakpoints I can see Appchooser.Snoop() being called, and the Injector.Launch executes without error. As I step out and back into WindowFinder.AttachSnoop(), the error happens when I attempt to step into _windowUnderCursor.Snoop().

I haven't had a chance to look at the troubleshooting instructions yet. Will do so shortly.
Jun 11, 2013 at 3:19 AM
Edited Jun 11, 2013 at 6:12 AM
Eureka! I have trapped the error after some help from the troubleshooting instructions.

As I suspected along the way, the problem is due to group policy in my locked down environment. After I enabled breaking on all CLR exceptions and disabled "Enable just my code", I get an exception thrown at the ShowDialog(): in Shell.exe:
System.Security.Policy.PolicyException occurred
  Message=Required permissions cannot be acquired.
       at System.Security.SecurityManager.ResolvePolicy(Evidence evidence, PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset, PermissionSet& denied, Boolean checkExecutionPermission)
Now all I need to understand is what it's after and what to do about it!
Jun 11, 2013 at 6:57 AM

I've managed to get past the Policy Exception. I had to recompile the ManagedInjectorLauncher being used (32-4.0) to conform to the same security rules as it did in .NET 2.0 (fortunately I've had to do this before and realised I just had to add the following code to the AssemblyInfo.cs file:
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Here's an article that covers the subject in depth.

Now I'm getting the original error at the top of this discussion, so hopefully I can now diagnose the error.
Jun 11, 2013 at 7:29 AM
And success.

Your theory about Powershell bears out. If I comment out the InitShell() line it works. Putting a try/catch around it also works:
            catch {}
I think it will be important for those of us impacted by group policy to enforce the old security rules on ManagedInjectorLauncher32-4.0 and ManagedInjector64-4.0 (the .NET 4 ManagedInjectors). I don't think this will affect people in more open environments, but if you're nervous about this change maybe these DLLs could be provided as a separate download?

Anyhow, I traced the problem to EmbeddedShellView's constructor on line 43 (Open()). Here's the exception detail:
System.TypeInitializationException occurred
  Message=The type initializer for 'System.Management.Automation.SessionStateScope' threw an exception.
       at System.Management.Automation.SessionStateScope.AddSessionStateScopeDefaultVariables()
  InnerException: System.InvalidOperationException
       Message=Dynamic operations can only be performed in homogenous AppDomain.
            at System.Runtime.CompilerServices.CallSiteBinder.BindCore[T](CallSite`1 site, Object[] args)
            at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
            at System.Management.Automation.Language.PSVariableAssignmentBinder.ObjectRule(CallSite site, Object obj)
            at System.Management.Automation.PSVariable.CopyMutableValues(Object o)
            at System.Management.Automation.PSVariable.SetValueRawImpl(Object newValue, Boolean preserveValueTypeSemantics)
            at System.Management.Automation.PSVariable..ctor(String name, Object value, ScopedItemOptions options, Collection`1 attributes)
            at System.Management.Automation.SessionStateScope..cctor()
Let me know if you need any more help. A lot of people at my work will need this fixed once our new Windows 8 SOE rolls out.
May 14, 2014 at 9:00 PM
So, I am getting the same (original error) on my personal machine and Snoop 2.8.0.

Snoop 2.7.1 runs fine and I use it to debug frequently.