AccessViolationException on Vista if not run in debugger?! [modified]
-
Hi! I'm using a COM DLL from a third party to access some hardware. The main application is written in C# and I can create the object and use it on XP without problems using an interop assembly created with tlbimp. When I try the same on Vista SP1, I get an AccessViolationException on the first method call into the COM object. The really weird thing is: The COM DLL only crashes when I call my application outside of VS, i.e. when I'm not trying to debug it. When stepping through the code in VS (2005 SP1), everything works as on Windows XP! Running the same executable from the debug directory crashes... Can anyone explain this behaviour or tell me where to look next? Thanks in advance! Update: The DLL also crashes in VS when I turn off the VS host process or when I first start the application and attach the debugger. So the big question is: What exactly does this VS host process do to keep the DLL from crashing?
Regards, mav -- Black holes are the places where God divided by 0...
modified on Tuesday, August 19, 2008 7:05 AM
-
Hi! I'm using a COM DLL from a third party to access some hardware. The main application is written in C# and I can create the object and use it on XP without problems using an interop assembly created with tlbimp. When I try the same on Vista SP1, I get an AccessViolationException on the first method call into the COM object. The really weird thing is: The COM DLL only crashes when I call my application outside of VS, i.e. when I'm not trying to debug it. When stepping through the code in VS (2005 SP1), everything works as on Windows XP! Running the same executable from the debug directory crashes... Can anyone explain this behaviour or tell me where to look next? Thanks in advance! Update: The DLL also crashes in VS when I turn off the VS host process or when I first start the application and attach the debugger. So the big question is: What exactly does this VS host process do to keep the DLL from crashing?
Regards, mav -- Black holes are the places where God divided by 0...
modified on Tuesday, August 19, 2008 7:05 AM
-
Just a guess - Does the COM DLL depend on any external files? If yes, ensure these file are located in the correct directory.
Sohail
Hi! Thanks for your reply, but I think that doesn't explain the behaviour. The DLL in question doesn't have any "unusual" dependencies and it does work on XP and when run inside VS...
Regards, mav -- Black holes are the places where God divided by 0...
-
Hi! Thanks for your reply, but I think that doesn't explain the behaviour. The DLL in question doesn't have any "unusual" dependencies and it does work on XP and when run inside VS...
Regards, mav -- Black holes are the places where God divided by 0...
-
Well once we had this problem when a colleague was using a 3rd party DLL in a .NET project using Interop. Hence I said I am guessing. To find the cause of your problem, more details would be required.
Sohail
Hi Sohail! Just wanted to inform you (and everybody else interested) that the problem indeed was inside the 3rd-party dll. They used ATL from VS2003 for their component and this caused a problem with Vista's DEP (an explanation can be found here[^] Turning off DEP made the problem go away. Jeez - how do people find out these things?:confused:
Regards, mav -- Black holes are the places where God divided by 0...
-
Hi Sohail! Just wanted to inform you (and everybody else interested) that the problem indeed was inside the 3rd-party dll. They used ATL from VS2003 for their component and this caused a problem with Vista's DEP (an explanation can be found here[^] Turning off DEP made the problem go away. Jeez - how do people find out these things?:confused:
Regards, mav -- Black holes are the places where God divided by 0...