0
Fixed

Event Broker 3.0.1 service crash "Object reference not set to an instance of an object."

Mark Southwell 12 years ago updated by anonymous 8 years ago 13

Hi Team,

Looks like the issue discussed in the issue below is back, the Event Broker service terminates and needs be be restarted.

https://unifysolutions.jira.com/browse/EB-412

Event log extracts:

An unhandled exception occurred and the process was terminated.

Application ID: Unify.Service.Event.exe

Process ID: 13932

Exception: System.NullReferenceException

Message: Object reference not set to an instance of an object.

StackTrace: at Unify.Framework.FileBasedLogWatcher.ReadFileLines()
at System.IO.FileSystemWatcher.CompletionStatusChanged(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* overlappedPointer)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

Application: Unify.Service.Event.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
Stack:
at Unify.Framework.FileBasedLogWatcher.ReadFileLines()
at System.IO.FileSystemWatcher.CompletionStatusChanged(UInt32, UInt32, System.Threading.NativeOverlapped*)
at System.Threading.ExecutionContext.runTryCode(System.Object)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)

Faulting application name: Unify.Service.Event.exe, version: 3.0.1.3, time stamp: 0x4ecc3390
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x000007ff0196adff
Faulting process id: 0x366c
Faulting application start time: 0x01ccad8c5d0fba05
Faulting application path: C:\Program Files\UNIFY Solutions\Event Broker\Services\Unify.Service.Event.exe
Faulting module path: unknown
Report Id: 6f38e0f9-1af0-11e1-a4fa-005056b40047


Unify.Framework.LogReader.dll
Unify.Framework.LogWriter.dll

Hi Mark,

Adam has a patch that may prevent any behaviour like this occurring, but we would need to confirm under what circumstances you encountered this error to be sure. Could you please upload any relevant Event Broker logs (such as around the time this occurs), your Extensibility directory, and any other relevant information (eg. when did this occur, time/circumstance)?

Cross reference to EB-343 as it seems to be the same thing happening @ DEEWR. Looking like it's SCOM that's doing it more than Symantec end point protection (which I was able to manually restart without crashing EvB just now)

Further to this Mark, I think that KB2004121 might be the key to solving this problem @ DEEWR. Perhaps it might be the key for your issue too?

Thanks Bob - I will confirm if that hotfix has been applied.

Hi Mark and Bob,

I have attached a couple of dll's that I'd like you to test for me if possible. (Just place them in the Event Broker services directory.)

I have eliminated a possible race condition during the disposal of an object. This was occurring during the change over of a log file, which occurs either on the change over of the day, or the start-up of the service.

I know it's hard to prove that it has worked, as the problem was intermittent, but please try to keep an eye on the behaviour, and let me know how it goes.

Thanks.

Thanks Adam - will try this in DEV.
Also Mark - on the hotfix - it seems that this should be unnecessary if you're already on Win 2008 R2 (which has it baked in).

Adam/Mark - this appears to have resolved the problem @ DEEWR (I have rebooted the FIM VM twice now and each time there is no problem any more with the EvB service failing to start). Mark - if you can confirm this works for you, then I am happy for you to mark this as resolved.

Thanks Guys, will try those DLLs at ACT Gov when I'm next on site (Monday).

This is to both Mark and Bob, though I'm assigning it to Bob so he gets an email notification as Mark already will as the reporter.

Do either of you have an updated on this that would enable us to close it off? Have you had any more problems with or did Adam's fix work?

Hi Patrick - SS ICT are still running V3.0.1 if I recall. No issues reported - however I think any issues would be masked by configuration to restart the service automatically on failure - this has been set on a number of services on the prod server. Will email Konrad at SS ICT and advise him to upgrade to 3.0.2.

Closed.

The race condition was removed, and no further evidence of the problem was presented.

As I am not going to be active on the DEEWR site again until mid-May, I am unable to instigate any patching, so this will need to be at the discretion of the customer - are they advised of this patch being available by virtue of their JIRA account? If I become aware of a problem when I re-engage, I will advise them to patch.