Click here to Skip to main content
15,749,072 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
hi guys,
I have a program that uses a third paty dll to filter records on my DB. This works fine on 32-bit systems that i have tested on. However, moving it to the main server (64-bit Windows Server 2008 R2) the program doesn't work anymore. It doesn't even start up. The very first lines of the program are supposed to log it's start up progress, and also report of any failures. It doesn't log anything.
It keeps raising a class not registered error (something like that), even though i've already registered d .dll file with wow64/regsvr32 on the 64-bit server.

Pls can anyone help with this situation as i've searched and found no answers yet.


In addition to SA;

His answer is more detailed comparing to mine but I also want to add this;

In 64-bit Windows there are two Registries.
These are;
A registry for 32-bit applications, and the other for 64-bit applications. It’s structured so that a 64-bit applications accessing HKLM\Software\Foo will access the 64-bit Registry, and a 32-bit app using the exact same path will access the 32-bit Registry instead.

your application by default is running in 32-bit mode on 32-bit versions of Windows. This means that it will be accessing the 32-bit Registry, and will only be able to talk to 32-bit libraries.

If all you are trying to do are simple things like reading/writing paths from the Registry just change your Registry code (that wants to get to the 64-bit Registry) to access HKLM\Software\Wow6432Node\Foo instead of HKLM\Software\Foo.


You may want to deploy your project for any cpu;

*AnyCPU - executed in 32bit on a 32bit runtime and 64bit on a 64bit runtime
*x86 - forced to execute in 32bit
*x64 - forced to execute in 64bit (will not work on 32bit OS)
*(IA64 - Itanumim)

So in order to do that you should change your deployment settings;

"Target Plattform" is in both cases "Any CPU" and also in the configuration manager all the project of the solutions should be set to "Any CPU".

Also sometimes problems may occur if you use unsafe constructs(ex: PInvoke) or if you specifically build your assemblies for a target platform.
Share this answer
Sergey Alexandrovich Kryukov 20-May-11 15:53pm    
Very good and useful notes.
I disagree with idiotic vote of 2 you got. I voted 5 (or, I see, it's a low-rank vote of 2).
What, somebody think we're supposed to return a fully-fixed project in code? So my vote compensates this (but the real reason of my vote was you good answer, of course).

Orcun Iyigun 20-May-11 16:52pm    
Thanks for the upvoting, I totally agree. Some people think that we are psychic and can solve their problems in an instant instead of taking the recommendation for granted.
There is too little information to say anything certain.

Just few items to check up.
There are three main different instruction-set architectures supported by Windows: 32-bit x86 ([^]) and two 64-bit ones: IA-64 "Itanium ([^]) and x86-64 ([^]).

They are all incompatible with each others, but all 32-bit applications will run on any 64-bit Windows OS on the platform WoW64 (Windows 32-bit On Windows 64-bit), which is a 64-bit subsystem to run 32-bit applications, see[^].

Now, why your application may fail to run? Because any of the three instructions-set architectures are incompatible if you try to link them in a single executable. They will compile but will crash when attempted to run in a single process. Of course, running components using different architectures and communicating through IPC (remote procedure call, DCOM — you name it) is not a problem.

You might end up messing up different components in one process as you run it on 64-platform. Some components might rely on system components, but those are now different. It's hard to sort out. First, you need to consider two options: 1) porting everything into your 64-bit instruction-set architecture or 2) running everything as 16-bit on WoW64.

To do that, you will need to learn all your dependencies. Use Microsoft Dependency Walker:[^].

Do you use any .NET components? There is another issue with them. As they are JIT-compiled, there is a special instruction-set architecture target: "Any CPU". The this is the option of the entry assembly of the application, it means that the real target architecture to be used is defined by the OS. If this is a library, the architecture is defined by setting of the referencing assembly. It all works, but if one of the assemblies is compiled with some concrete instruction-set architecture target and if there is a contradiction, the application will crash during run-time. Same thing happens if your application use P/Invoke of some native Windows code (unmanaged). It will crash unless instruction-set architectures match.

You see, so many potential source of trouble. You need to take a serious investigation.

Share this answer
Yosh_ 19-May-11 15:26pm    
Thanx, SA. But it still doesn't help me much. You hv only pointed me in many directions which i shall explore. Hope this works.
Sergey Alexandrovich Kryukov 20-May-11 15:48pm    
Think about it: nothing help you much more than that. You did not deliver your project for a fix; you did not here a consultant for a fix. How anyone could provide you with more help based on as much information as you provided?

Your ***only*** in "only pointed me" sounds ridiculous.

By the way, I'm just curious? Did you vote really 2 and 3 for the answers? By what reason?
Orcun Iyigun 20-May-11 16:46pm    
Yes I am also curious about it if he is the one voted for the answers.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900