1

I recently upgraded an application from .net 3.5 to 4.0. Since I did that, with debug settings to break on all exceptions enabled, I've been getting a few of these exceptions each time I start a section of the application that connects to a database using the EF. The exact number is variable; sometimes I only get one, others several in rapid succession.

ReleaseHandleFailed was detected Message: A SafeHandle or CriticalHandle of type 'Microsoft.Win32.SafeHandles.SafeCapiHashHandle' failed to properly release the handle with value 0x06AD3D08. This usually indicates that the handle was released incorrectly via another means (such as extracting the handle using DangerousGetHandle and closing it directly or building another SafeHandle around it.)

I never got exceptions like this when targeting 3.5. These exceptions don't have any meaningful call stack attached, all I get is [External Code], denying any easy way to localize where they're coming from. The reason I suspect EntityFramework is somehow involved is that one section of the app uses nHiberate instead doesn't generate any of these messages.

To run down other dependencies that might be involved: In all cases, the ORM is talking to an Sql Compact database MS Sync Framework 2.1 is being used to update the local DB from SqlServer. The Entity framework models have been regenerated with the 4.0 framework, and I upgraded the cache DB to v4.0 as well.

Since there's no call stack I'm not sure if these messages fall into the category of "harmless" errors automatically cleaned up internal to the framework; or if there's an exception eater catching them elsewhere in the application.

Dan Is Fiddling By Firelight
  • 5,981
  • 17
  • 77
  • 128
  • As an example of the "harmless" internally handled exception type, if you don't have SGen in your build process; the first time you do XmlSerialization of a type within a project a Foo.XmlSerializers.dll exception is thrown, but the framework automatically recovers and does the serialization with no indication of the issue presented to the user/developer unless debug options are set to break on all exceptions instead of just unhandled ones. – Dan Is Fiddling By Firelight Oct 12 '12 at 16:09
  • EF does not internally use any native or unsafe code. Also look at this thread: http://stackoverflow.com/questions/3512531/releasehandlefailed-exception – Pawel Oct 12 '12 at 16:43
  • I saw that thread; but it didn't have anything useful. There's no unsafe code anywhere in my app; if EF can't be responsible I'll have to look more closely at the other dependencies; but offhand nothing else is jumping out for the pattern of what parts of the app it is happening in. – Dan Is Fiddling By Firelight Oct 12 '12 at 17:34

1 Answers1

6

This is not an exception, it is a Managed Debugging Assistant warning. You might have gone over-board a bit when you changed the settings to "break on all exceptions enabled". Debug + Exceptions, Managed Debugging Assistants node, untick the "ReleaseHandleFailed" warning. It is off by default.

The MDA catches an old bug that's gone undetected for a while in the AesCryptoServiceProvider class. Backgrounder is here.

Judging from your comment, you are about to make a drastic mistake. You do not solve this by avoiding encryption or compromising your dbase connection security. You accidentally turned on an MDA that's normally off. MDAs in general tend to produce false warnings and many of them are turned off by default. The warning is in fact bogus, releasing the handle failed because it was already released. This happens in the finalizer thread, that's why you don't get a stack trace. And thus can't easily find out what code uses the class in the first place.

The proper way to fix it is to use the Debug + Exceptions dialog properly. Fix the problem you created by clicking the Reset All button. Then click only the Thrown checkbox for Common Language Runtime exceptions. That's what you are trying to debug.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Keep your eye on the ball, it is not an exception. And the problem detected by this MDA is not caused by other people's code. Well, it's Microsoft code. Nothing you can actually fix. – Hans Passant Oct 12 '12 at 20:16
  • I just tested with all of my connections to SqlServer set to use SqlServer authentication but with `Encrypt=False` in the connection string. I'd've expected that change to have knocked `AesCryptoServiceProvider` out of the execution path but the MDA is still being raised. – Dan Is Fiddling By Firelight Oct 12 '12 at 20:54
  • You are about to make a Big Mistake. I added two more paragraphs to the answer. – Hans Passant Oct 12 '12 at 22:39
  • What made you think I made, or had any intention of making, this change in production; vs fiddling around with dummy data in my development environment? – Dan Is Fiddling By Firelight Oct 12 '12 at 23:29
  • Well, obviously because I have no idea why you even pursued what you tried as described in your last comment. Which is why I expanded the answer. If it is of no use to you then feel free to ignore the advice, answers are meant to be useful to *anybody* that might land on this question some day anyway. – Hans Passant Oct 12 '12 at 23:35
  • The reason I tried taking the crypto out of the picture is that your linked answer indicated that this was a problem in the 3.5 framework as well, but I never encountered it then. As a result, I'm wondering if it was originating elsewhere; n which case I don't know if it's a harmless false positive. – Dan Is Fiddling By Firelight Oct 12 '12 at 23:36
  • You are really missing the core of the answer. This went wrong when you started clicking checkboxes in the dialog. That's where it originated. – Hans Passant Oct 12 '12 at 23:37
  • At this point, I think we're talking past each other. The amount of time I've lost due to default settings and estimated time I've saved due to stopping on more things is several times larger than what I've spent chasing potential false positives. As a result, for the code bases I'm working with the optimal amount of stuff to be checked is more than the default; and I can't find any guidance from MS on which items are most likely to generate false positives instead of detecting legit problems. – Dan Is Fiddling By Firelight Oct 15 '12 at 12:45
  • As a result, I'm reluctant (but due to an inability to find the root cause, will probably have) to disable this particular warning without being able to confirm that it is a false positive. While you've found one case where the framework does trigger false positives, the evidence appears to indicate that what I'm encountering (your bug existing in 3.5; but my code only triggering it in 4.0; and an unencrypted test build still triggering it) is coming from somewhere else. – Dan Is Fiddling By Firelight Oct 15 '12 at 12:46