1

I am having some issues with my WPF Windows C# application. Whenever the application is closed, it throws a System.ObjectDisposedException. The problem seems to only occur when it is compiled in 32-bit. The 64-bit build runs fine without throwing any exception.

From the exception message, it says cannot access a disposed object but it doesn't seem to tell what object is causing the issue - How do I find out the object that has been disposed?

Exception:Thrown: "Cannot access a disposed object." (System.ObjectDisposedException) A System.ObjectDisposedException was thrown: "Cannot access a disposed object." Time: 1/19/2016 5:16:28 PM Thread:[1552]

Exception Info: System.ObjectDisposedException Stack: at System.Diagnostics.EventLogInternal.OpenForWrite(System.String) at System.Diagnostics.EventLogInternal.InternalWriteEvent(UInt32, UInt16, System.Diagnostics.EventLogEntryType, System.String[], Byte[], System.String) at System.Diagnostics.EventLogInternal.WriteEntry(System.String, System.Diagnostics.EventLogEntryType, Int32, Int16, Byte[]) at System.Diagnostics.EventLog.WriteEntry(System.String, System.Diagnostics.EventLogEntryType) at HP.HPTRIM.SDK.TrimApplicationBase.UnregisterStackTrace(System.Object, Int32) at HP.HPTRIM.SDK.Database.internal_Dispose() at HP.HPTRIM.SDK.Database.Finalize()

Irshad
  • 3,071
  • 5
  • 30
  • 51
K Hsueh
  • 610
  • 1
  • 10
  • 19
  • Is `HP.HPTRIM.SDK` your code? –  Jan 20 '16 at 01:41
  • It is a .dll file that my code is using – K Hsueh Jan 20 '16 at 01:43
  • Either you disposed the HP database earlier or it's a buggy 3rd party SDK. Is there more to the stack trace? –  Jan 20 '16 at 01:45
  • I'm not familiar with HP TRIM specifically, but a Google search suggests that there are different HP TRIM libraries for compiling against 32-bit versus 64-bit. When compiling in 32-bit are you switching to 32-bit libraries? – cokeman19 Jan 20 '16 at 01:52
  • 1
    @cokeman19 I'd say he would be because otherwise you get the dreaded Bad Image Format exception. –  Jan 20 '16 at 02:13
  • Yes, I switch to the 32 bit libraries when compiling in 32 bit and the stack trace above is all I have got in Visual Studio. Just found the object name that is causing the problem under the Locals panel: [System.ObjectDisposedException] {"Cannot access a disposed object.\r\nObject name: 'EventLogInternal'."} Would the problem be coming from the event log instead or it is irrelevant? – K Hsueh Jan 20 '16 at 02:48

3 Answers3

2

Possibly this is too late to be useful but I stumbled on this because I've recently encountered a very similar (identical?) issue when using the HP Records Manager SDK (v8.3 in my case). I believe I've identified the cause.

There was a bug in my own code (an executable using the HP .Net SDK to connect to HPRM) where I hadn't called Dispose() on one of its SDK objects).

It seems that when the GC comes along to clean up as the executable exits, HP decides it wants to write a message to the Windows Application Event Log, pointing out that a developer forgot to .Dispose() of the object properly. For whatever reason, though, there seems to also be a bug in the HP SDK whereby, at this time, it'd disposed of its internal system for writing to the Event Log. (Sometimes it works for me, sometimes not. Probably a race condition somewhere in the SDK.)

The consequence was that after the end of my code, the .Net Framework jumped up and screamed about the HP SDK's attempt to use a disposed object for writing to the event log.

The immediate fix for me was to fix my own code. Once I'd disposed of all the objects I was meant to (specifically a Database connection I'd created), the chain of events wasn't kicked off. Really, though, the HP code also seems to be buggy.

Irshad
  • 3,071
  • 5
  • 30
  • 51
MikeM
  • 64
  • 4
0

If you look at the last line of the stack trace you will see that the problem is being caused in the Dispose() of an HP.HPTRIM.SDK.Database object.

Jens Meinecke
  • 2,904
  • 17
  • 20
0

This isn't as much of an answer as it is too long to render usefully in a comment.

I spent some time in ILSpy looking at the EventLog class. That innermost method in the exception, EventLogInternal.OpenForWrite, is designed to explicitly throw an ObjectDisposedException when one of its internal flags is set. (And though it's always possible that the ObjectDisposedException you're receiving is not specifically from this line, it is interesting to note.)

private void OpenForWrite(string currentMachineName)
{
    if (this.boolFlags[256])
        throw new ObjectDisposedException(base.GetType().Name);
    ...
}

The flag it's checking only gets set when that EventLog instance's Dispose method has been called, meaning the EventLog instance is actively disposing. Since this is something out of your control, this may be a bug in HP TRIM's HP.HPTRIM.SDK.Database's IDisposable implementation, since one of the two HP methods listed in the exception would hold the reference to the EventLog instance.

It's also worth noting that it's possible this exception is triggered because the HP.HPTRIM.SDK.Database instance is not being disposed properly (assuming its IDisposable) during application close and is just being allowed to fall out of scope. As a test, you might try disposing your HP.HPTRIM.SDK.Database instance sometime that's not during application close and see if you can replicate the error.

What any of this would have to do with the bitness, I can't say.

Irshad
  • 3,071
  • 5
  • 30
  • 51
cokeman19
  • 2,405
  • 1
  • 25
  • 40