Rank: Advanced Member
Groups: Member
Joined: 7/14/2014
Posts: 40
|
While using EO.Pdf v6.0.21.2 (from NuGet) today we ran into an application crash and the following was reported:
Application: ...
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Security.SecurityException
Stack:
at System.Diagnostics.EventLog.FindSourceRegistration(System.String, System.String, Boolean, Boolean)
at System.Diagnostics.EventLog.SourceExists(System.String, System.String, Boolean)
at System.Diagnostics.EventLog.SourceExists(System.String)
at EO.Pdf.Internal.ma.a(System.String)
at EO.Pdf.Internal.ma.a(System.Object, System.Threading.ThreadExceptionEventArgs)
at System.Windows.Forms.Application+ThreadContext.OnThreadException(System.Exception)
at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
at System.Windows.Forms.UnsafeNativeMethods.PeekMessage(MSG ByRef, System.Runtime.InteropServices.HandleRef, Int32, Int32, Int32)
at System.Windows.Forms.UnsafeNativeMethods.PeekMessage(MSG ByRef, System.Runtime.InteropServices.HandleRef, Int32, Int32, Int32)
at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
at EO.Pdf.Internal.ma.g()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart()
And second
Faulting application name: ..., version: 2.0.0.2, time stamp: 0x545c3881
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17278, time stamp: 0x53eebf2e
Exception code: 0xe0434352
Fault offset: 0x000000000000606c
Faulting process id: 0xdf8
Faulting application start time: 0x01d0057bc35e122f
Faulting application path: ...
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: 5e9f4877-74b5-11e4-80d8-005056b7419d
Faulting package full name:
Faulting package-relative application ID:
Why is EO.Pdf attempting to access the EventLog? Was this just some debug/test code that was inadvertently left in the project?
My past experiences with errors from EO.Pdf were always captured by my application code. However in this case the code didn't catch the exception at all and it bubbled all the way out to an application crash. The more I look at the stack trace, the more I think that this is from some other thread(s) that the EO.Pdf functionality is spawning and I'd like to know if there's any way to contain/bottle these exceptions so that the application (a windows service in this case) won't crash abruptly.
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
You will want to temporarily grant permission so that those logs can be written. When EO.Pdf runs, it has two parts: one part that runs inside your process and another part that runs outside of your process. Most of the converter code, particular the WebKit rendering engine, are run outside of your process in a different worker process. This architecture ensures that if anything bad happens in the worker process, it will crash the worker process, but not your process. And your process will be able to detect such cases and act accordingly.
Under normal conditions these two parts talk to each other so that if anything goes wrong anywhere, it will eventually propagate back to your code as an exception. However under extreme conditions (for example, a crash inside the worker process), the communication channel between the in process part and the worker process might have already broken. In that case the worker process will be unable to tell your process exactly what went wrong, in this case it will try to write some additional debug information into the event viewer to help you to troubleshoot the problem (The code that runs inside your process will still be able to detect that the worker process has died and throw an exception, but it won't be able to tell you exactly why the worker process has died). That's why you will want to temporarily grant permission so that you can see those event log entries written by the worker process because they may lead you to the root of the problem.
Thanks!
|
Rank: Advanced Member
Groups: Member
Joined: 7/14/2014
Posts: 40
|
eo_support wrote:You will want to temporarily grant permission so that those logs can be written. What permission exactly? Which event log? And what source? The main application runs under an account that already has permission to write to the application event log - most of the EO.Pdf errors are bubbled up through the usual channel and end up getting written out to the event log. I'm not an expert on the internals of .NET but based on the call stack shown in the application crash report it looks like perhaps the problem is that the event source the code is expecting trying to use isn't registered with the system. eo_support wrote:In that case the worker process will be unable to tell your process exactly what went wrong, in this case it will try to write some additional debug information into the event viewer to help you to troubleshoot the problem (The code that runs inside your process will still be able to detect that the worker process has died and throw an exception, but it won't be able to tell you exactly why the worker process has died). I understand why you're using this fallback mechanism to provide some way to report the details of the crash (though wouldn't WER do a crash dump report of the child process?). What I don't get however is that you're saying it's that the child process can't communicate back and so it (the child process) is crashing on writing the information to the event log. If that's the case then: 1) Why is the faulting application and application path to our application? 2) Why is our application crashing? Shouldn't the faulting application be listed as worker process? Shouldn't my application have as you said, detected the death of the worker process and throw an exception but not have details on why it died? All of our references to EO.Pdf functionality are wrapped in try/catch blocks. Based on the call stack I'd say it looks like your code is spawning other threads within our application process space and it was one of those threads (and not the worker) that threw the exception while trying to write to the event log. If the worker died then what would it (running in the host process) know other than the death of the worker? Those threads need to be contained so that exceptions aren't getting thrown but rather reported back through the normal mechanism (absolute worst case - saved for the next time the functionality is called within the process lifetime).
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi, You are correct that this can be inside your process as well. We have confirmed this after further reviewing the code. However we still do not know why you run into that error when your application does have sufficient permission. The source code that causes the error is:
Code: C#
if (!EventLog.SourceExists("EO.Pdf"))
EventLog.CreateEventSource("EO.Pdf", "Application");
So you might want to try the above code directly and see if you get the same error as well. Thanks!
|
Rank: Advanced Member
Groups: Member
Joined: 7/14/2014
Posts: 40
|
eo_support wrote:However we still do not know why you run into that error when your application does have sufficient permission. The source code that causes the error is:
Code: C#
if (!EventLog.SourceExists("EO.Pdf"))
EventLog.CreateEventSource("EO.Pdf", "Application");
So you might want to try the above code directly and see if you get the same error as well. Yes that is a little odd that the SourceExists check would cause an exception. I'll do a little research, run a few tests, and then get back to you.
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
No problem. In the mean time we will put a try catch block around this code block. In that case the application will still crash (due to the exception), but Windows might log down the original exception message (which is the message we are trying to write into the event viewer but failed) instead of the error caused by EventLog.SourceExists call. The change will be in our next build.
Thanks!
|