| Groups | Blog | Home |
dotnet interop : Runtime error creating a Visio drawing surface in .NET 2.0
Hi all.
I have an application that embeds multiple Visio documents using the Visio drawing surface control (Microsoft Visio 11.0 Drawing Control Type Library). It was working fine on VS.NET/.NET 1.1, but after I moved to VS 2005/.NET 2.0, customers started reporting the runtime error below. It seems to happen on the second instance or later. I've already spent a week stabbing in the dark at this. Any help would be appreciated. ************** Exception Text ************** System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at System.Windows.Forms.UnsafeNativeMethods.CoCreateInstance(Guid& clsid, Object punkOuter, Int32 context, Guid& iid) at System.Windows.Forms.AxHost.CreateWithoutLicense(Guid clsid) at System.Windows.Forms.AxHost.CreateWithLicense(String license, Guid clsid) at System.Windows.Forms.AxHost.CreateInstanceCore(Guid clsid) at System.Windows.Forms.AxHost.CreateInstance() at System.Windows.Forms.AxHost.GetOcxCreate() at System.Windows.Forms.AxHost.TransitionUpTo(Int32 state) at System.Windows.Forms.AxHost.CreateHandle() at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.AxHost.EndInit() at CustomLib.ctlDrawingView.InitializeComponent() at CustomLib.ctlDrawingView..ctor(clsTreeNode& node) at CustomLib.DocumentView.RefreshView() at CustomLib.ViewManager1.ShowPage() at CustomLib.ViewManager1.HandleSelectedIndexChanged(Object sender, EventArgs e) at System.Windows.Forms.TabControl.OnSelectedIndexChanged(EventArgs e) at System.Windows.Forms.TabControl.WmSelChange() at System.Windows.Forms.TabControl.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll ---------------------------------------- CustomApp Assembly Version: 1.9.2.5620 Win32 Version: 1.9.2 CodeBase: file:///C:/Program%20Files/Vendor/CustomApp/CustomApp.exe ---------------------------------------- CustomLib Assembly Version: 1.0.2223.1948 Win32 Version: 1.0.2223.1948 CodeBase: file:///C:/Program%20Files/Vendor/CustomApp/CustomLib.DLL ---------------------------------------- Microsoft.VisualBasic Assembly Version: 8.0.0.0 Win32 Version: 8.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Data Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Web Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Web/2.0.0.0__b03f5f7f11d50a3a/System.Web.dll ---------------------------------------- System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Transactions Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Transactions/2.0.0.0__b77a5c561934e089/System.Transactions.dll ---------------------------------------- System.EnterpriseServices Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.EnterpriseServices/2.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll ---------------------------------------- AxInterop.VisOcx Assembly Version: 11.0.0.0 Win32 Version: 11.0.0.0 CodeBase: file:///C:/Program%20Files/Vendor/CustomApp/AxInterop.VisOcx.DLL ---------------------------------------- VisiToolsToolbar_Addin Assembly Version: 11.0.1037.0 Win32 Version: 11.0.1037 CodeBase: file:///C:/Program%20Files/Visimation/VisiTools/VisiToolsToolbar_Addin.dll ---------------------------------------- Extensibility Assembly Version: 7.0.3300.0 Win32 Version: 7.00.9466 CodeBase: file:///C:/WINDOWS/assembly/GAC/Extensibility/7.0.3300.0__b03f5f7f11d50a3a/Extensibility.dll ---------------------------------------- Microsoft.Office.Interop.Visio Assembly Version: 11.0.0.0 Win32 Version: 11.0.3216 CodeBase: file:///C:/WINDOWS/assembly/GAC/Microsoft.Office.Interop.Visio/11.0.0.0__71e9bce111e9429c/Microsoft.Office.Interop.Visio.dll ---------------------------------------- Microsoft.Office.Interop.VisOcx Assembly Version: 11.0.0.0 Win32 Version: 11.0.3216 CodeBase: file:///C:/WINDOWS/assembly/GAC/Microsoft.Office.Interop.VisOcx/11.0.0.0__71e9bce111e9429c/Microsoft.Office.Interop.VisOcx.dll ---------------------------------------- CustomMarshalers Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.42 (RTM.050727-4200) CodeBase: file:///C:/WINDOWS/assembly/GAC_32/CustomMarshalers/2.0.0.0__b03f5f7f11d50a3a/CustomMarshalers.dll ----------------------------------------
Hi Dave,
Based on my research, it seems that I can not reproduce the problem. Here are my steps. 1. Create a winform application in VS.NET 2005 2. Add a Tab Control with two Tab pages 3. Add a visio control on each Tab page, so there are two visio control in all. 4. Set the Src property to load visio file for the two visio control 5. Run the application and switch between Tab1 and Tab2 there are no error. if I have any misunderstanding, please feel free to post here. I think you may try the steps to see if you can reproduce the problem with the steps above. If no, I think you need to add code block one by one to see what is the cause. Best regards, Peter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
It sounds like you've captured the essence of the scenario. I have a very hard time reproducing the error myself on the build machine (2000) or a test machine (XP), but my customer says they get it regularly. I'll send them a special build like you described and post the code if we can isolate the error. Thanks. -Dave [quoted text, click to view] ""Peter Huang" [MSFT]" wrote:
> Hi Dave, > > Based on my research, it seems that I can not reproduce the problem. > Here are my steps. > 1. Create a winform application in VS.NET 2005 > 2. Add a Tab Control with two Tab pages > 3. Add a visio control on each Tab page, so there are two visio control in > all. > 4. Set the Src property to load visio file for the two visio control > 5. Run the application and switch between Tab1 and Tab2 there are no error. > > if I have any misunderstanding, please feel free to post here. > > I think you may try the steps to see if you can reproduce the problem with > the steps above. > If no, I think you need to add code block one by one to see what is the > cause. > > Best regards, > > Peter Huang > Microsoft Online Partner Support > > Get Secure! - www.microsoft.com/security > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Dave,
Thanks for your update! Also I think you may try to reinstall(Remove,Install) the visio application, I wonder if there is anything corrupted with the Visio application. Best regards, Peter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
Ok, I finally managed to isolate the problem, which wasn't easy because I can't reproduce it locally. I created a user control with nothing but a Visio drawing surface, and a form with a panel and a button on it. The button's handler contains the following code: Panel1.Controls.Clear() c.Dispose() c = New UserControl1 Panel1.Controls.Add(c) c.Src = System.IO.Directory.GetCurrentDirectory & "\test1.vsd" The pivotal line is the second line that forces disposal of the visio drawing surface. If I take it out, the application no longer crashes but there is a bad resource leak. I don't know why the GC doesn't take care of this. The resulting error is the same as originally reported - a memory access violation in System.Windows.Forms.UnsafeNativeMethods.CoCreateInstance, ultimately invoked from the EndInit function. I suspect that something in the library is attempting to access memory associated with a previous instance of the control that has already been released. That might explain my difficulty in reproducing it. [quoted text, click to view] ""Peter Huang" [MSFT]" wrote:
> Hi Dave, > > Thanks for your update! > Also I think you may try to reinstall(Remove,Install) the visio > application, I wonder if there is anything corrupted with the Visio > application. > > Best regards, > > Peter Huang > Microsoft Online Partner Support > > Get Secure! - www.microsoft.com/security > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi
Based on my understanding, I assume the c is a UserControl when you want to dispose it in the second line. Panel1.Controls.Clear() c.Dispose() c = New UserControl1 Panel1.Controls.Add(c) c.Src = System.IO.Directory.GetCurrentDirectory & "\test1.vsd" I just wonder why you need to call the Dispose method here explictly. Also GC has its own algorithm to schedule when to run, because a keep running GC thread will hit the performance. Commonly we implement the IDispose and call the Dispose when we want to release the Unmanaged Resource, because GC have no idea about the unmanaged world. It managed the Managed Resource. GC did the job that call the Finalize, commonly is the deconstructor in the C++ term. Commonly we did not need to explicitly call the Finalize, it is handled by GC. Here is link for your reference. Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework http://msdn.microsoft.com/msdnmag/issues/1100/gci/ Garbage Collection¡ªPart 2: Automatic Memory Management in the Microsoft NET Framework http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx Resource Management http://msdn2.microsoft.com/en-us/library(d=robot)/22d8keek.aspx Best regards, Peter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
The GC thing had me wondering too, but I can verify empirically that the
resources are never freed if I don't call it directly, and my customers curse my application in the afternoon when it brings their 2GB PCs to their knees. But that aside, I would expect that it is acceptable to call the Dispose method in this situation (the reason we would have to could be relevant, or that could be a separate question altogether), so my question remains as to why the dll is crashing when a new instance of the drawing surface is initialized. I determined that the crash doesn't happen unless the last instance of the control is destroyed. So I can work around the problem by declaring an instance of my UserControl (with the drawing surface) that never gets destroyed. This is an acceptable, though ugly, workaround for the issue at hand, but I hope this information could help lead to a more appropriate solution. [quoted text, click to view] ""Peter Huang" [MSFT]" wrote:
> Hi > > Based on my understanding, I assume the c is a UserControl when you want to > dispose it in the second line. > > Panel1.Controls.Clear() > c.Dispose() > c = New UserControl1 > Panel1.Controls.Add(c) > c.Src = System.IO.Directory.GetCurrentDirectory & "\test1.vsd" > > I just wonder why you need to call the Dispose method here explictly. > Also GC has its own algorithm to schedule when to run, because a keep > running GC thread will hit the performance. > > Commonly we implement the IDispose and call the Dispose when we want to > release the Unmanaged Resource, because GC have no idea about the unmanaged > world. It managed the Managed Resource. GC did the job that call the > Finalize, commonly is the deconstructor in the C++ term. Commonly we did > not need to explicitly call the Finalize, it is handled by GC. > > Here is link for your reference. > Garbage Collection: Automatic Memory Management in the Microsoft .NET > Framework > http://msdn.microsoft.com/msdnmag/issues/1100/gci/ > Garbage Collection¡ªPart 2: Automatic Memory Management in the Microsoft > .NET Framework > http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx > > Resource Management > http://msdn2.microsoft.com/en-us/library(d=robot)/22d8keek.aspx > > Best regards, > > Peter Huang > Microsoft Online Partner Support > > Get Secure! - www.microsoft.com/security > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi,
Commonly for a winform application, in the application's lifetime, once we create a usercontrol, we did not destroy it until when the winform application exited. But that will cause a lot of resource recreate which will hit the performance. So I just wonder why we need to create/destroy the usercontrol frequently. Did you have special requirement? e.g. you will show your customers two visio files in the meantime, we just need to create two instance visio control and change the view by changing the Src property of the control. For your scenario about why it will crash, based on my experience, a problem as complex as this may take extensive time to narrow down. Also it needs lower level debugging or dump analysis. I think you may need to work with Microsoft Customer Service and Support (CSS) for a faster resolution. Once you open a Support incident with Microsoft CSS, a dedicated Support Professional can work with you in a more efficient manner. http://support.microsoft.com Thanks for your understanding! Best regards, Peter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |