read-event cmdlet never returns

May 21, 2009 at 12:40 AM

 

 

 

 

I've been using PS Eventing for over a year now in our production application. We just recieved some new production systems and installed our software including ps eventing on to them and the read-event is never returning on these new systems. Just sits there forever even though the event we are watching for has fired. The new production systems are identical to the older systems with the exception of maybe a few microsoft patches. I tried to look at your code through reflector but really didn't see anything. Can you give me insight into what may cause the read-event to never return?  The new systems are Windows 2003 Server SP2 32-bit, same as the existing systems we have.<font face="Courier New" size="2" color="#0000ff"><font face="Courier New" size="2" color="#0000ff"><font face="Courier New" size="2" color="#0000ff">

function

</font></font></font><font face="Courier New" size="2" color="#0000ff"><font face="Courier New" size="2" color="#0000ff">

 

</font></font><font face="Courier New" size="2" color="#0000ff">

 

</font>

DoEvents([int]$EventCount) {<font face="Courier New" size="2"><font face="Courier New" size="2">

 

</font></font><font face="Courier New" size="2">

 

</font>

 

if ((get-pssnapin pseventing -ea silentlycontinue) -eq $null) {add-pssnapin pseventing}

 

<font face="Courier New" size="2"><font face="Courier New" size="2">

 

</font></font><font face="Courier New" size="2">

 

</font>

 

$InternalEventCount = 0;

 

start-keyhandler -capturectrlc

<font face="Courier New" size="2"><font face="Courier New" size="2">

 

</font></font><font face="Courier New" size="2">

 

</font>

 

trap { stop-keyhandler }<font face="Courier New" size="2"><font face="Courier New" size="2">

 

</font></font><font face="Courier New" size="2">

 

</font>

 

do {<font face="Courier New" size="2"><font face="Courier New" size="2">

 

</font></font><font face="Courier New" size="2">

 

</font>

 

$events = @(read-event -wait)

...

}

}

Coordinator
Jul 20, 2009 at 6:34 PM

Sorry Joey - I haven't been monitoring these discussions - I thought I had subscribed to alerts, but I hadn't. Are you still having a problem?

Jul 20, 2009 at 11:19 PM

Hi, I worked with Microsoft and they helped identifiy the root problem but we are just bypassing the issue right now which is not ideal because the bypass may fail at anytime in the future. The case number is [REG:109061781418045]. In your code, where you drop into IL, you are expecting all events to have the System.EventArgs as the last parameter. Since the majority of the APIs we work with do not have System.EventArgs it is failing with a JIT error when your assembly is compiled in Release mode. We could add this as the last parameter to our events but it would be a lot of work and ultimately does not make for a clean API. Plus we use some API's that we don't have source code for so its not an option with those. I found the only workaround which is to compile the PS Eventing assembly in Debug mode and somehow this doesn't cause JIT to bomb even though your code is explicity looking for System.EventArgs.

I'm not an IL expert. Is there any way to re-write it so that the last argument of an event does not have to be System.EventArgs?

 

The Microsoft Case Rep sent this: (The yellow highlighted lines are what he recommended we add to our events signatures)

The PSEVENting API is expecting another argument in the event handler which is of type System.EvenArgs. But in the testAPI, this argument is not passed to the event handler.

 

As this is running with “Full Trust” ILVerficiation is not done at the load time. Because the verifier didn't run, you didn't get a verification exception.  Instead you got InvalidProgramException because the IL is *bad*. 

 

To make things work, please pass another argument of type System.EvenArgs to the event handler. Example below:

 

In the file Step.cs:

 

    // <summary>

    /// Step completed event handler

    /// </summary>

    public delegate void StepCompletedEventHandler(Step step, System.EventArgs arg);

 

                <snip>

 

Raise the event like this:

 

            if (StepCompleted != null)

            {

                //StepCompleted.GetInvocationList();

                StepCompleted(this, null); // <- Passed another argument null.

 

            }

 

                <snip>

 

 

This resolves the issue.

Thanks,

Ravi Kumar

 

Coordinator
Jul 21, 2009 at 3:14 AM
Edited Jul 23, 2009 at 4:05 PM

Hi Joe,

That's pretty odd for your API's events to not follow the standard delegate signature for events. However, please provide the delegate signatures you are working with and what you would expect from PSEventing and I'll see what I can whip up to help you. Please give me as much detail as you can.

Also, I'm not sure what you mean it would not be a clean api. sender, args is the de-facto .NET pattern for event delegates. If you do not use EventArgs, pass EventArgs.Empty. I think you're in for a nasty surprise if you expect powershell v2.0's built-in eventing to solve your problems; I'm pretty sure it expects the same, standard, signature too. updated: native v2.0 eventing works fine with non-standard event delegates, so ignore that one.

-Oisin