64 bit version?

By way of introduction: I am yet another silo refugee, who heard about voidworld on their forum. I've looked at a number of posts here and I think the results of nvil look quite impressive.

So, I was able to get nvil to run on a windows XP machine after locating the c runtime library and fiddling with permissions. But I mostly use windows 7 64 bit and I haven't been able to get nvil to run, it appears to throw a BadImageFormat exception. This can be caused by mixing 32bit or unmanaged dlls with 64bit code. Here's microsoft's blurb on this exception.

http://msdn.microsoft.com/en-us/library/system.badimageformatexception.aspx

It is also quite possible that I am doing something stupid. So does anyone know a fix for this? Will there be a 64bit version?

Hi Kevin, welcome to the forums.

I am running Nvil on win7 64 without the error you mention.

Nvil runs via .net 2 and MS Managed DirectX. I have run Nvil on this setup with ".net 4" installed, but not with ".net 4.5"(which you linked to for the error). Which (latest) version of .net framework do you have installed?

Could you post more info for the error (possibly error report from windows event viewer?).

Regards,

-Steve

kevin, please check this
http://voidworld.cmcproductions.co.uk/index.php/topic,75.0.html

Hi Kevin, welcome to the forums.

I am running Nvil on win7 64 without the error you mention.

Nvil runs via .net 2 and MS Managed DirectX. I have run Nvil on this setup with ".net 4" installed, but not with ".net 4.5"(which you linked to for the error). Which (latest) version of .net framework do you have installed?

Could you post more info for the error (possibly error report from windows event viewer?).

Regards,
-Steve

Sorry this is so long...
Thanks for the welcome - and for the help. If it works for you than it must be my configuration, right?

I have VS2010 on this PC - that is who caught the exception.

My registry shows .Net 4 (4.030319) as the latest, of course it also lists 3.5,3,and 2.

The summary of this exception is basically that 64bit and 32bit asswemblies are being mixed, which makes me wonder about the msvcrt71.dll that I copied off an XP(32bit) machine. The exact error shown is:

"System.BadImageFormatException was unhandled
Message:  is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)"

And below is the exact verbiage that the studio help system shows for this exception:

"
Troubleshooting Exceptions: System.BadImageFormatException    
Send Feedback
Updated: April 2011
A BadImageFormatException exception is thrown when the file image of a DLL or executable program is not a valid managed executable.
Associated Tips
________________________________________
If your application uses 32-bit components, make sure that it always runs as a 32-bit application.
If the Platform target property for your application project is set to AnyCPU, the compiled application can be run in either
64-bit or 32-bit mode. When it runs as a 64-bit application, the just-in-time (JIT) compiler produces 64-bit native code.
If the application depends on a 32-bit managed or unmanaged component, that component will fail to load in 64-bit mode.
To correct this problem, set the project's Platform target property to x86 and recompile.
Make sure that you are not using a component that was created with a different version of the .NET Framework.
This exception is thrown when an application or component that was developed by using the .NET Framework 1.0 or the .NET
Framework 1.1 attempts to load an assembly that was developed by using the .NET Framework 2.0 SP1 or later, or when an
application that was developed by using the .NET Framework 2.0 SP1 or the .NET Framework 3.5 attempts to load an assembly
that was developed by using the .NET Framework 4. The BadImageFormatException exception may be reported as a compile-time error,
or the exception may be thrown at run time. See the BadImageFormatException class for an example.
Make sure that the file image is a valid managed assembly or module.
This exception is thrown when an unmanaged dynamic link library or executable is passed to the Load method for loading.
For more information, Visual Basic users can refer to Troubleshooting Interoperability (Visual Basic).
Remarks
________________________________________
Reflecting on C++ executable files may throw this exception. This is most likely caused by the C++ compiler stripping the relocation
addresses or the .Reloc section from the executable file. To preserve the .relocation address in a C++ executable file, specify /fixed:no when linking.
For more causes of this exception, see the BadImageFormatException class.
"

kevin, you may have missed my previous post. Please check this thread
http://voidworld.cmcproductions.co.uk/index.php/topic,75.0.html

Many people have come across this same problem. It is a missing dll.

The program is written in C# and runs at 32-bit.

It seems you computer tried to run it at 64-bit. Is there a way to specify to run it at 32-bit. I don't have a 64-bit machine.

kevin, you may have missed my previous post. Please check this thread
http://voidworld.cmcproductions.co.uk/index.php/topic,75.0.html

Many people have come across this same problem. It is a missing dll.

The program is written in C# and runs at 32-bit.

It seems you computer tried to run it at 64-bit. Is there a way to specify to run it at 32-bit. I don't have a 64-bit machine.

I'm sorry IStonia, are you referring to the msvcr71.dll? Because I copied that one into the nvil directory. Is there another one I missed seeing in that other thread? I think that before I copied the dll I got a missing file error.

And win 7 64bit has "compatibility modes" where you can run 32bit applications as if on a 32bit XP system. But it must be some configuration problem, because steve can run it okay. I have two PCs running win7 64bit and it won't run on either of them. Of course they are setup very similar to each other. Frustrating.

Hi Kevin,

..........are you referring to the msvcr71.dll? Because I copied that one into the nvil directory. Is there another one I missed seeing in that other thread? I think that before I copied the dll I got a missing file error.

I did not think it was the missing dll, as that usually causes nvil to crash on startup and not give bad_image errors.

Can you check the version of msvcr71.dll you copied over. The version I have is 7.10.6030.0 (size on disk:- 348,160 bytes)

Regards,

-Steve

"System.BadImageFormatException was unhandled
Message:  is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)"

The software is compiled to x86 platform and is definitely 32-bit.

Okay I think I know what is wrong and well, it is a little embarrassing. So I apologize for wasting you guys time. I downloaded the dll from that link in the other thread, and that works. So I beleive what happened is that the usb stick that is "approved" for use at work automatically encrypts files unless you specifically decrypt it. Which I'll bet I forgot to do. I didn't want to have to download from a third party site, so I copied the one from my work PC. So, again, sorry and thanks for the help. I am looking forward to using this program.

I guess the encrypted dll confused the OS into choosing to throw that exception.

Hi Kevin,

Good to hear you found the problem. (saves me continuing to check what framework/images Nvil is loading)

If you have more than 4gb of memory on your 64bit setup, you may want to look at setting Nvil to LAA (Large Address Aware). It will double the memory Nvil can use.
There is a small application that can be used, download from :- http://www.techpowerup.com/forums/showthread.php?t=112556

Hi Kevin,

Good to hear you found the problem. (saves me continuing to check what framework/images Nvil is loading)

If you have more than 4gb of memory on your 64bit setup, you may want to look at setting Nvil to LAA (Large Address Aware). It will double the memory Nvil can use.
There is a small application that can be used, download from :- http://www.techpowerup.com/forums/showthread.php?t=112556

Neat tip. And very interesting voodoo. I say voodoo because I don't fully understand it - so it must be magic, right? I would have thought this to be compile-time target dependent. You sometimes see binary patches to fix older executables, for instance. Does this work because of virtualization?