 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Interop / February 2006Runtime 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  SignatureGet 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 > Hi Dave, > [quoted text clipped - 21 lines] > 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 SignatureGet 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. > Hi Dave, > [quoted text clipped - 10 lines] > 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 SignatureGet 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. > Hi > [quoted text clipped - 35 lines] > 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 SignatureGet Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.