.NET 2.0 SP1 causes NullReference exception in framework class finalizer that crashes application.
After installing .NET 2.0 SP1 I'm encountering a NullReference exception at the location shown below:
> System.Windows.Forms.dll!System.Windows.Forms.AxHost.OleInterfaces.AttemptStopEvents(object trash = null) + 0x1a bytes
This triggers when a call is made to GC.Collect() after disposing of the dialog that contained an ActiveX control. Because our application is an Office addin this exception crashes the Office application. Attempting to trap the unhandled exception does not avoid the crash.
Prior to installing .NET 2.0 SP1 the application was operating flawlessly for some time so I am certain this is a bug in the framework. Looking at the code for the AttempStopEvents method in the OleInterfaces class:
private void AttemptStopEvents(object trash)
{
if (this.connectionPoint.threadId == Thread.CurrentThread.ManagedThreadId)
{
this.StopEvents();
}
}
The framework code is not checking if connectionPoint is null, most other methods are checking this. AttemptStopEvents is posted onto the message loop from the OleInterfaces finalizer.
The Disposing of the AxHost control causes OleInterfaces.StopEvents to be called which set connectionPoint to null and sets up the failure when the finalizer calls the above AttemptStopEvents method.
All Replies
To troubleshoot this issue, we really need the source code to reproduce the problem, so that we can investigate the issue in house. It is not necessary that you send out the complete source of your project. We just need a simplest sample to reproduce the problem. You can remove any confidential information or business logic from it.
You can send a sample project to may email address which can be found in my personal mail address.
Thank you for replying. A MS Partner support incident has been opened for this issue and the is being analyzed by developer support. Reproducing the problem involves licensed 3rd party controls that cannot be posted to the forums.
I have same problem on my form. Have you found a solution ?
Cem
As a work around, you can use reflection to get access to the oleSite member of the AxHost object and than supress it's finalizer.
The code sample can be found here:
http://www.xpidea.com/Support/KnowlegeBase/tabid/65/Default.aspx
Sincerely,
Alex CherkasovUnfortunately I haven't gotten anywhere with MS support yet, they see the crash down but they are unable to re-create the problem in-house with the sample I sent. However I'm able to do it on every machine I've tried all with very different hardware and software installed. Getting this bug to occur requires another certain type of control to be present which is really bizzare. In my case I need a particular 3rd party .NET control present, even though this control is not ActiveX and does not even need to be on the form being disposed.
Do you or anyone have a small sample application that causes this bug to appear? If so can you please contact me so I can send it to MS support.
Dave
I believe MS should take a word on it -there is no need to reproduce it, since definitely its a threading issue in the destructor of the class causing null reference exception in the thread pool posted by Post(), after connection point was disconnected by the Finalizer thread through StopEvents().
There should be definitely a check for the connectioinPoint field being null.
See my code above to work around.
The MS support team is now able to reproduce the problem so I don't need another sample. The issue has now been escalated...again. Alex's fix stops the crashes, however I'm not sure if it will ensure 100% cleanup as the AttemptStopEvents in the finalizer exists for a reason and this bug is hard to produce. Supressing the finalizer on OleInterfaces could stop a legitimate and required cleanup if the bug is not occurring.
I am very pleased that at least they have accepted the problem exists. Anyways can you please give me the incident or ticket number so I can see the bug report and hopefully when they find a solution I will get notified. If you can not do that please post to this forum so we know what to do.
FYI: I also have a third party control in my solution not on the form I have the ActiveX. and I am using .NET 3.5 but I think it does not matter sonce 3.5 uses the dll's from 2.0
I am having the same issue and thought it was with Crystal Report Viewer. I have pinpointed it to be service pack 1 of .NET Framework 2.0 . Several of my customers had contacted Dell and got a work arround by uninstalling .NET Framework 2.0 sp1 and re-installing just .NET Framework 2.0 without the service pack.
Can you please give me an incident # or your contact at MS so that I can resolve this issue?
Thanks In Advance
Update on this...it has been escaled for a 2nd time to the Visual Studio team (why them...I don't know, Windows Forms team was on it). Today I got a lousy workaround to try from MS that doesn't work. It involved doing a GetOcx() call and releasing the ActiveX control from under AxHost. This failed miserably with "COM object has been seperated from RCW errors" inside the framework.
The incident number is gold partner support for my organization, so giving it out won't help as they will only talk to the partner contacts for that incident and will insist you go through the normal support channels (also meaning they'll want you to pay for it). Putting the support tech's email in this public forum and having everyone start emailing him will just complicate things.
If you have an MS developer support plan or partner support please submit an incident for it. This increases the severity of the issue and put pressure toward getting a framework patch quicker instead of a developer workaroud. This bug is definitely going to break applications in the field.
I won't leave you all hanging and will keep updating this thread on the status of this and if there is a better workaround given. So far, the suggested workaround of using reflection to get the OleSite member and doing a SupressFinalize is the best bet if this bug occurs %100 of the time. There may be a possiblity of a very small memory leak on each closed dialog from it, however that is preferrable to outright crashing.
Our company is an ISV and has a MS Support Plan and it would help considerably to have a reference to the incident number purely so that we do not have to re-explain the issue to the support representative.
My issue is closely related but I still would like to reference your incident to speed along the escalation.
My issue is solely with Cystal Report XI Report Viewer Control that is throwing this exception. The resolution to this problem will have to be rectified by Microsoft or BusinessObjects teams since I do not have access to the source for the ReportViewer Control. My application is a VB.NET windows Application and is crucial line of business application for my customers. The only work arround at this stage available to my customers is to remove all .NET Framework and service packs and install only .NET Framework 2.0 without service Pack 1. Dell was kind enough to provide us with a tool to remove and cleanup the registry for .NET Framework 2.0 service pack 1.
Any information you could provide to help me escalate an incident at MS would be appreciated.
Ok, tell them to refer to Case # SRX071213601892. It's been through multiple people and teams so far and they have a sample already that sets up the conditions for it.
I have an update on this issue. The workaround given above by Alex has been approved by Microsoft as an acceptable workaround to this problem. The workaround is to supress the finalizer on the oleSite object when must be obtained through reflection and must be done on the parent Form or Control containing the AxHost control. The workaround code is as follows:
FieldInfo fi = typeof(System.Windows.Forms.AxHost).GetField("oleSite",
BindingFlags.Instance |System.Reflection.
System.Reflection.
BindingFlags.NonPublic); object o = fi.GetValue(axHostControl); GC.SuppressFinalize(o);Where "axHostControl" is the AxHost control is question. For production code you'll want to at least enclose the above in a try-catch. This workaround should not lead to a memory leak, however you should test your production code to be sure.
There are two approved ways to apply the above workaround, but it can probably be applied in other ways as well.
- For a Form control, the above should be done in the FormClosing event or in an OnFormClosing override method.
- For a control class dervied from Panel, UserControl, etc. override the WndProc method and do the above workaround when a WM_DESTORY message arives (m.Msg == 2).
Because there is a workaround for our case, there will NOT be a hotfix created which unfortunately doesn't help with applications already in the field. If you need a hot fix please contact Microsoft support and make a case for it. Keep in mind that either way the fix for this bug in the framework won't get automatically distributed until the next .NET 2.0 service pack which would likely be over a year from now.
- I am trying to implement this fix into a VB.NET project and having problems with it. Could I impose upon you to repost that code snippet above in VB.NET as well?
The fi declaration specifically is what I can't get to work.
FieldInfo is in the System.Reflection namespace, so you'll need a using statement for it or change it to System.Reflection.FieldInfo.
My decompiler spits out the code in VB as a single line:
GC.SuppressFinalize(GetType(AxHost).GetField("oleSite", (BindingFlags.NonPublic Or BindingFlags.Instance)).GetValue(Me.<Control>))
Where <Control> is the variable of the AxHost derived control causing the problem.
- Thank you sir. That was exactly what I was looking for syntacticly. Now if I can get it put in the right place to stop the error, I'll be golden. Much appreciated.
Could you provide some code in VB that I could apply to a Crystal Report Viewer control?
My application only has the problem when I view a crystal report in the Report Viewer control and the crystal report parameter dialouge appears and the user close the dialouge - then when they move the mouse over the report I experience the nullreference exception -
I was going to use one of my support cases at Microsoft but if you could provide some lead way that would save considerable time trying to explain it to MSDN.
Thanks
- I'm sorry to keep bugging you about this. I have multiple AxHost based controls on multiple forms. The exact same error you reported is happening to me when I instantiate a new instance of any form in my project.
It's an MDI application and I'm assuming that the Main MDI form is attempting to Dispose one of the four AxHost controls it uses whenever I attempt to open a new form. However, posting that SuppressFinalize code in an over-ridden Dispose method isn't helping, nor in the FormClosing event.
@ the user asking about VB.NET for his Crystal Reports control. Use this:
GC.SuppressFinalize(GetType(AxHost).GetField("oleSite", (System.Reflection.BindingFlags.NonPublic Or System.Reflection.BindingFlags.Instance)).GetValue(Me.<TheNameOfYourAxControlHere>)) The only thing I can think of that would be happening is that there is another AxHost control not accounted for. This happened to me and drove me nuts for half a day. I suggest trying to commenting out or removing controls to narrow down exactly which one was causing it.
One thing that made testing easier was making a button/menu command to do a few GC.Collect calls, or placing GC.Collect calls somewhere in the code where it gets calls repeatedly such as the Form constructor. This will trigger the bug as quickly possible.
If all else fails you might have to bite the bullet and open a MS incident for it. If you have a case where there is no possible way to make this workaround work then you'll have request a hot fix.
What really worries me is what happens with libraries running around from Microsoft or a 3rd parties that has a complex or multi-part controls inside that might be an AxHost derived control. There won't be any way to apply this fix for such cases.
> What really worries me is what happens with libraries running around from Microsoft or a 3rd parties that has a complex or > multi-part controls inside that might be an AxHost derived control. There won't be any way to apply this fix for such cases.
Ugh... I was just thinking the same thing. We use a Janus suite of controls that include a bunch of things from complex grids to scheduling controls. I really don't want to have to go through and update all those controls to their .NET versions just to fix this.
I'm in the process of commenting out controls now. I very much appreciate the help, the GC.Collect menu is a good tip for testing and I'm going to implement that immediately it should help me quite a bit. Thanks again sir, you've been a lot of helpI'm using the Janus controls suite also. I believe Janus has stated that they don't use any COM/ActiveX controls inside GridEX or any of their UI library controls. We have heavy usage of GridEX as well as their UI drop combo, list boxes, and color picker button, so I can definitely say you shouldn't be getting this bug from GridEX of any of their UI suite controls.
Oh wait...did you say you're using the ActiveX version of the Janus suite and not the .NET version? That could be very bad because GridEX has many child control parts. You should contact Janus about that.
- I just double checked and we are indeed using a .NET version of their GridEx control. The Calendar\Scheduler control we have is the ActiveX version though. However, I'm getting the error without touching any portion of the application that includes that control at the moment so I don't think that's what's causing it. We have an ActiveX version of an Outlook style Icon control strip that I think is the culprit right now. It's the only thing left on my main MDIForm that could be causing it at the moment, I've removed every other control already and am still getting the error.
I'll keep plugging away. Some days I just love my job... lol I am also using Janus .NET control sweet, specifically on the form that is causing the problem I am using the Ribbon Control and Panel Manager. I tried to create a reproducable project but was not able to cause the problem with the Crystal report viewer control . I might switch to non-janus controls on this form and see the outcome - I am now suspecting somethings up with Janus controlls. Thats too much of a coincidence and my Devexpress and Infragistics controls of similar nature are not causing the problem.
Just some input.
Have you tried notifying Janus on their forums? They usually respond very quickly and put out patches every 2-4 weeks usually. Plus it costs nothing. Two of their libraries have new patches from within the last few weeks.
- I can assure you that if you're using the .NET versions of the Janus control suites, they are not your issue.
Look in the control instantiation portion of your form for anything that resembles the following.
Public WithEvents <name of your control here> As Ax....
When you see that, go to the FormClosing event of that form and put this code into it.
GC.SuppressFinalize(GetType(AxHost).GetField("oleSite", (System.Reflection.BindingFlags.NonPublic _
Or System.Reflection.BindingFlags.Instance)).GetValue(Me.<name of your control here>))
That will fix the issue. I had quite a few forms that I was pre-loading during application start-up that were being GC'ed and causing my issue. Once I found all my AxHost controls I put the GC.SuppressFinalize on all of them. Then removed it until I found the two controls that caused the issue and put it in place through out my application where they were used.
Now I'm writing documentation to start the removal process of them. Yay for service packs...
There are no ax controls on my usercontrol or form to apply the suggested code. I am using only the standar Crystal Report viewer control and Janus Controls . All of which are .NET and not activex controls.
The problem only occurs with reports that have parameters and the Report viewer control displays those report parameters in a dialog box (form) which I have no control over, this is entirely built into the report viewer control so I would have no access to that dialogues closing event to place this code.
Again, when I excluded the Janus Controls in a repro project the problem disappeared.
As mentioned above, I was incorrect and Janus controls are not the issue , the issue is the developer team at Microsoft and what they unfortunately removed from the .Net Framework 2.0 with SP1.
I am currently involved in a case with Microsoft - srx080129601059 and also Business Objects Case ID 302906678
I was told by Microsoft that they are be bombarded with calls about this issue and that they have escalated the issue and the developer team at MS will be providing a Hotfix
As mention before, the more individuals that submit cases , the faster we will get the hotfix
The problem also persists in .Net Framework 3.5 so updating your project to the latest framework will not solve the issue nor will updating to Crystal Reports 2008
Hello - I know this is an old post but I have a Crystal Parameter report causing this problem in a .net 2 Framework VB.net application. Was there a published hotfix or workaround to resolve this?
Thanks
KerrinHi, I also have the same problem which was described by Kerrin Banner. It's quite an old post, but it seems there is still no solution for it. Is there any Microsoft KB article which handles this issue?
We also have a .NET application, using .NET 2.0 SP1 and Crystal Reports (we use the Reportviewer), and when we try to print a document which has additional parameters, we get the error "nulreference exception..."
Help!
