1. Skip to navigation
  2. Skip to content
  3. Skip to sidebar



Echelon Knowledge Base

Question
An LNS application created using Visual Studio 2008 (VS2008 or VS2005 with .NET Framework 2.0 SP1) runs successfully on Windows XP, but fails on Windows Vista with the following error: "Creating an instance of the COM component failed"

Question Detail

My LNS application runs fine on Windows Operating Systems other than Vista, but if I use Vista, it fails to create the Object Server COM component and shows the following error message:

 "Creating an instance of the COM component with CLSID {104B7F00-06EE-11CF-9AE0-0020AFD34749} from the IClassFactory failed due to the following error: 80040023"

Solution

The cause of this error is an access violation when LNS tries to create its event window, which is hidden.  The access violation is actually caused by a Data Execution Protection (DEP) violation.

There are a number of factors which can lead to the cause of this problem:

1)  Visual Studio 2008 (or VS2005 with .NET Framework 2.0 SP1), by default, specifies the linker option /NXCOMPAT, which means that the application is known to be compatible with DEP (this prevents the application from being excluded from those that are checked for DEP violations in the system's DEP dialog, and also prevents the ATL compatibility tweaks from occurring).  This is a 'breaking change' introduced by Microsoft in their newer compilers.

2)  At the system level there is a DEP OptIn vs OptOut policy setting (only for 32-bit applications), which may be set to OptOut by default on Vista platforms supporting hardware NX.  Windows XP SP2 also has this setting, so this problem may exist there too, if .NET Framework 2.0 SP1 has been installed on the build machine, and OptOut is set on the Windows XP client machine.

Microsoft Knowledge Base article #948468, http://support.microsoft.com/kb/948468 describes the problem in more detail and suggests a number of resolutions, including:

1)  Rebuild the application with the /NXCOMPAT:NO C++ linker option.
2)  Use EditBin /NXCOMPAT:NO {application.exe} to remove the NXCOMPAT attribute that marks the application as DEP-compatible.
 

Resolution number 1 is recommended.
Resolution number 2 can be used by end-users to help them with existing applications that (incorrectly) have the /NXCOMPAT attribute set.
 

To test whether an application has the NXCOMPAT attribute set, you can run the following command:

 
"DUMPBIN /HEADERS {application.exe}"  (where the DUMPBIN version is greater or equal to V8.00.50727.42)
 
Look for the phrase "NX compatible" under the Optional Header Values > DLL Characteristics section.
 
Note that the C# (and VB.Net) compiler for VS2008 and VS2005 (when .NET Framework 2.0 SP1 is installed) now automatically sets the NXCOMPAT bit . For more information please refer to the following links:
<http://blogs.msdn.com/ed_maurer/archive/2007/12/14/nxcompat-and-the-c-compiler.aspx>
<http://blogs.microsoft.co.il/blogs/sasha/archive/2007/12/21/dep-nxcompat-net-2-0-sp1.aspx

This solution applies to the following products:

  • LNS 3.0
  • LNS Turbo Edition (Ver 3.2)

Last Modified: 09/03/2009
Solution: KB668