NET 2.0 Service Pack 1 causes report writer unhandled exception

[Sandy Pham]

I installed .NET 2.0 Service Pack 1 and the report writer has started getting "unhandled exceptions" that cause my app to shut down.

System.NullReferenceException was unhandled
Message="Object reference not set to an instance of an object."
Source="System.Windows.Forms"
StackTrace:
at System.Windows.Forms.AxHost.OleInterfaces.AttemptStopEvents(Object trash)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)


I googled the error and found this is a bug in the service pack related to ActiveX controls. I see that you StiWebBrowser is using ActiveX, but I didn't see any other places. I'm using everything except your web stuff. Is there any other place you are using ActiveX that you could fix?

From http://forums.microsoft.com/MSDN/ShowPo ... 4&SiteID=1

"This issue is due to a bug that was introduced with Service Pack 1 of .NET Framework 2.0.

This bug has to do with new code that we added to the AXHost class within the System.Windows.Forms namespace that deals with how ActiveX controls are handled in the application. The code was added to correct some other bugs related to the disposal of ActiveX controls that had occurred in the original .NET Framework 2.0 release. Essentially the bug is that we are attempting to dispose of some internal objects on another thread, and our code does not check to see if the object is null before accessing it. In some circumstances, the object is null and therefore we crash with the NullReferenceException.

We have reported the bug and have requested it be fixed in the next service pack of .NET 2.0. For a workaround, you can use code similar to the following on any forms that contain ActiveX controls. This will keep us from running the problem code internally and should avoid the crash.

Private Sub Form1_FormClosing(ByVal sender As Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing

Dim host As AxHost
Dim t As Type
Dim fi As System.Reflection.FieldInfo
Dim o As Object

'Assumes MyActiveXControl is the name of the ActiveX control on the form

If Not IsNothing(MyActiveXControl) Then

host = CType(MyActiveXControl, AxHost)

t = GetType(AxHost)

fi = t.GetField("oleSite", System.Reflection.BindingFlags.Instance Or _

System.Reflection.BindingFlags.NonPublic)

o = fi.GetValue(host)

GC.SuppressFinalize(o)

End If

End Sub"

Someone else also posted this solution:

GC.SuppressFinalize(GetType(AxHost).GetField("oleSite", _
(System.Reflection.BindingFlags.NonPublic Or System.Reflection.BindingFlags.Instance)).GetValue(Me.tvwReport))

Thanks,

Sandy

[Edward]

Thank you very much for this information and the solution you'd proposed as well

[Sandy Pham]

When do you think you will be able to fix this problem?

Thanks,

Sandy

[Sandy Pham]

My co-worker was helping me troubleshoot this. He went to the disassembler for the code when it crashed and then quick-watched the "this" pointer. It is definitely the StiWebBrowser class that is causing our problem. If you can fix this, it will fix our problem.

Thanks!!!

Sandy

[Edward]

Yes, it is true, StiWebViewer uses some ActiveX controls. It is the only component in the Stimulsoft Reports.Net which uses ActiveX.

We shall provide a patch in next Monday.

Thank you.

[Sandy Pham]

Thank you!!!

By the way, Microsoft has released their suggested workaround for the bug. In case you're interested:

http://support.microsoft.com/default.aspx/kb/948838

[Vital]

Patch will be available 14 Feb.

p.s. Thanks for bug report.

[Vital]

Please check build from 16 Feb.

Thank you.

[Sandy Pham]

Hi Vital,

Please help! We still have a problem with the NET 2.0 Service Pack 1 bug. I traced your source code and figured out that it happens when "Closing=True" in the DockingPanels.config file. When Closing=False, your fix works fine. However, when Closing=True we get the .NET null reference exception when we press the Preview tab inside the designer.

--This causes a problem:


StiPropertiesPanelService



--This works fine:



StiPropertiesPanelService




It looks like when Closing=True, the StiWebBrowser control gets created twice because StiDesigner.Refresh() gets called twice.


We have customers that are waiting for this fix so they can use the Report Writer again. We would REALLY APPRECIATE it if you could fix this additional problem (since we do not expect Microsoft to fix their bug any time soon).


Thanks so much!

Sandy

[Vital]

Patch for this problem will be available in build from 25 Feb.

Thank you.