Eventhandler not triggered

[Guest]

Hi all,

I have a problem with an application that is consuming events from an
unmanaged dll.

I use the following pseudo-code to create and register my eventhandler:

System.Threading.WaitHandle myEvent = new AutoResetEvent(false);

// Register the event to my eventhandler
RegisteredWaitHandle myEventHandleReg=
ThreadPool.RegisterWaitForSingleObject(myEvent, new
WaitOrTimerCallback(myEventHandler), this, 1000, false);

I also call a function in the unmanaged dll where one of the arguments is a
reference to myEvent to register the event there.

This has been working like a charm during application tests and development
but now in my production enviroment I have started to experience problems.
The eventhandler is not triggered as often as I would like it to.

Could this be related to heavy load on my system (processor busy)?

The events are raised pretty much 500 ms apart all the time and if my
application for some reason is busy for 1000 ms would that result in an event
not being able to trigger the eventhandler or will the events line up in a
queue and get processed when the application is ready?

Is there any reason to use a ManualResetEvent to maybe be more robust?

Any suggestions would be appreciated

Best regards
Henrik

 

[Jeffrey Tan[MSFT]]

Hi Henrik,

This looks like a complex issue, which may not easy to troubleshoot the
root cause, since your application works well in most of the testing
situations.

Based on my understanding, your application is using
ThreadPool.RegisterWaitForSingleObject to execute the *myEventHandler*
every 1000ms or when "myEvent" is pulsed. This "myEvent" is passed to an
unmanaged dll, so that you can trigger the *myEventHandler* by pulsing the
"myEvent" AutoResetEvent. In production environment, the *myEventHandler*
may not be executed while pulsing "myEvent" in the unmanaged dll in special
condition.

To identify if this problem is caused by heavy system load in production
system, I recommend you to run your application in that system under low
CPU condition, will the problem still occur? Also, does the problem occur
in one client prodution machine?

This production issue looks like to be caused by race condition in the .Net
application, maybe the multithreading issue between .Net background threads
and the worker threads. Actually, such type of issue really hard to
troubleshoot due to newsgroup support nature. So I recommend you contact
Microsoft PSS to give it a deep debugging, the Microsoft PSS engineer may
help to do a remote debugging on the production machine. I think this will
be more efficiency to find out the root cause.

Also, as the MSDN sample suggested, using AutoResetEvent should be correct,
I do not think ManualResetEvent will resolve the problem.

Finally, since the ThreadPool.RegisterWaitForSingleObject internally uses
WaitForMultipleObjects win32 API to wait and execute the *myEventHandler*,
personally, I prefer using Process Explorer to monitor the
WaitForMultipleObjects thread, and find out whether it will wake up while
"myEvent" is pulsed. However, since the "myEvent" pulsing is too
fast(500ms), it is not hard to use this approach.

Anyway, I will try to consult internally to find out what is the most
recommended debugging method for this scenario.

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thank you for your reply

Just to clearify this issue:

I use the "myEvent" to react to events that occur in hardware that I have
purchased and the supplier of this hardware also supplies an unmanaged dll
with methods to interact with the device.

The standard operation of the whole system is like this:

1. The "myEvent" triggers the "myEventHandler" telling my application that
data is availiable for my application to process.
2. The eventhandler calls the device throug the dll to get the data.
3. The data is processed.

The supplier of the device tells me that events could get lost if I do
extensive processing in the thread that waits for the event but he is from an
unmanaged enviroment not familiar with the thread pool.

My understanding of the Threadpool.RegisterWaitForSingleObject is that every
time my event is signaled a thread (let's call it "thread1") from the
threadpool is taken and used to process the event and since the "myEvent"
event is AutoReset it will immidiately start listening for new events.
If a new event is triggered before "thread1" is finished processing another
thread from the threadpool will handle the second event.

Is my understanding correct? If not, how does it work?

Best regards,
Henrik

Hi Henrik,

This looks like a complex issue, which may not easy to troubleshoot the
root cause, since your application works well in most of the testing
situations.

Based on my understanding, your application is using
ThreadPool.RegisterWaitForSingleObject to execute the *myEventHandler*
every 1000ms or when "myEvent" is pulsed. This "myEvent" is passed to an
unmanaged dll, so that you can trigger the *myEventHandler* by pulsing the
"myEvent" AutoResetEvent. In production environment, the *myEventHandler*
may not be executed while pulsing "myEvent" in the unmanaged dll in special
condition.

To identify if this problem is caused by heavy system load in production
system, I recommend you to run your application in that system under low
CPU condition, will the problem still occur? Also, does the problem occur
in one client prodution machine?

This production issue looks like to be caused by race condition in the .Net
application, maybe the multithreading issue between .Net background threads
and the worker threads. Actually, such type of issue really hard to
troubleshoot due to newsgroup support nature. So I recommend you contact
Microsoft PSS to give it a deep debugging, the Microsoft PSS engineer may
help to do a remote debugging on the production machine. I think this will
be more efficiency to find out the root cause.

Also, as the MSDN sample suggested, using AutoResetEvent should be correct,
I do not think ManualResetEvent will resolve the problem.

Finally, since the ThreadPool.RegisterWaitForSingleObject internally uses
WaitForMultipleObjects win32 API to wait and execute the *myEventHandler*,
personally, I prefer using Process Explorer to monitor the
WaitForMultipleObjects thread, and find out whether it will wake up while
"myEvent" is pulsed. However, since the "myEvent" pulsing is too
fast(500ms), it is not hard to use this approach.

Anyway, I will try to consult internally to find out what is the most
recommended debugging method for this scenario.

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi Michael,

Thanks for your further information!

From the ThreadPool.RegisterWaitForSingleObject document:
"The wait operation is performed by a thread from the thread pool. The
delegate is executed by a worker thread when the object's state becomes
signaled or the time-out interval elapses."

So your understanding should be correct.

Can you tell me what version of .Net Framework you are using? Based on the
discussing with other experts, we find Microsoft had a bug in .Net 1.1 that
it would stop firing some timers. Please refer to #3 in the blog entry
below:
"ASP.NET & .Net Framework Hotfixes That Everyone Needs"
http://blogs.msdn.com/toddca/archive/2005/08/23/455116.aspx

It looks like they are the same issue, you may obtain the hotfix and have a
test to see if it fixes your problem.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

I'm using version 2.0 of the framework.

Does the hotfix apply to version 2.0 ?

/ Henrik

 

[Jeffrey Tan[MSFT]]

Ok, it seems that this hotfix does not apply to this issue yet. I will
still try to collect some more information. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi Henrik,

Sorry for letting you wait.

I have performed a further discussion with our senior escalation engineer.
He confirmed that this issue is not easy to debug and required me to
provide a dump file for troubleshooting this issue. Since the newsgroup is
not suitable for dump level debugging and support, I suggest you contact
Microsoft PSS for the further debugging, I am sure this is the more
efficient way for your issue.

You can contact Microsoft Product Support by contacting us at
1-(800)936-5800 or by choosing one of the options listed at
http://www.microsoft.com/services/microsoftservices/supp.mspx

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.