objectdisposedexception - Safe handle has been closed Pt 3

I don't know if this will help in the error, but I did come across a reference to add to the app.config of your app to set the following flag. This may mask other errors, and I haven't tested it out yet. But it is one more option to add:

legacyunhandledexceptionpolicy enabled="1"

Under the config section of the app.config.

objectdisposedexception - Safe handle has been closed Pt. 2

In doing some more research, I found this bit from a Microsoft Feedback page:

The issue reported to us occurs not because the iDB2NamedEvent class calls the Handle property, but because it calls it while the WaitHandle is registered with the ThreadPool through ThreadPool.RegisterWaitForSingleObject. This is not a valid operation.

The workaround is either to avoid closing the handle manually in the finalizer for the iDB2NamedEvent class (the runtime will take care of that anyway), or unregister the WaitHandle from the ThreadPool before closing the handle. Option 1 is probably preferable.

It sounds like this is the only case that you should not call the disposed method. Instead, let program clean it up on it's own. Yuck.

objectdisposedexception - Safe handle has been closed

It's been a while since I've posted, and here is my current issue. I'm writting a call from an asp.net webservice to an IBM as/400 storedproc via IBM's "IBM DB2 UDB for iSeries .NET Provider"

It works great! I have a stored procedure on the iSeries system that calls an internal program. I can make the call. However, when my project stops or closes down, I get an ObjectDisposedException, "Safe handle has been closed" I've seen a few posts here and there about it, and finally stumbled across this bit from IBM:

SE22506 - CA400EXP-IDB2DATA .NET PROVIDER WITH .NET FRAMEWORK 2.0
At least they have a patch. Though, I don't know how long it will take our team to get the patch installed, tested and move to production. Well, hopefully it won't take long.

But in any case, at least now I have a path to go down. And according to their records it will work on V5R2M0, V5R3M0, and V5R4M0. We'll see I guess.

If anyone has some other method for working around this error, I'd love to hear about it.