Keep in mind that the Action ScriptBlock for the registered events will execute within it's own scope. This means that if there are any errors during execution, you will not be able to normally see them. Thankfully PowerShell events work with Jobs, which you can use to help identify some issues.

Say for example the action block contains an invalid command:

$action = { CommandThatDoesNotExist }

If the event is registered, and nothing happens, you can use the Get-Job command to look for issues.

PS C:\> Get-job

Id              Name            State      HasMoreData     Location             Command
--              ----            -----      -----------     --------             -------
1               NewEventLog     Failed     False                                    ...

Looking at the results, we can see that Job ID 1 has a "Failed" State. To get more information, we can look at the resulting error.

PS C:\> (Get-job 1).Error

The term 'CommandThatDoesNotExist' is not recognized as the name of a cmdlet, function, script file, or operable progra
m. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:10 char:25
+  CommandThatDoesNotExist <<<<
    + CategoryInfo          : ObjectNotFound: (CommandThatDoesNotExist:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

An alternative suggested by PowerShell MVP Oisin Grehan (I forget where this was mentioned now), is to enter a nested prompt from your $Action

$Action = { $Host.EnterNestedPrompt() }

This will enter a nested prompt in the console, each time the event is raised and the action is run. Keep this in mind if you have a ton of events to be processed, as things will quickly get out of control. However, this can be a very good troubleshooting technique to step into the scope of your Action ScriptBlock for troubleshooting.

Last edited Jun 16, 2011 at 9:37 PM by sgrinker, version 2


No comments yet.