I bought a new computer recently and uploaded this project to a FTP server and then downloaded it to my new computer but now it is causing this error:
Unhandled Exception: System.InvalidProgramException: Common Language Runtime det
ected an invalid program.
at Nancy.Conventions.NancyConventions.<Validate>b__1(Tuple'2 result)
at System.Linq.Enumerable.WhereEnumerableIterator'1.MoveNext()
at Nancy.Conventions.NancyConventions.Validate()
at Nancy.Bootstrapper.NancyBootstrapperBase'1.Initialise()
at Nancy.Hosting.Self.NancyHost..ctor(INancyBootstrapper bootstrapper, HostCo
nfiguration configuration, Uri[] baseUris)
at Nancy.Hosting.Self.NancyHost..ctor(Uri baseUri, INancyBootstrapper bootstr
apper, HostConfiguration configuration)
at PokerServer.Program.startServer() in f:\Projects\Visual Studio\PokerServer
\PokerServer\Program.cs:line 93
at PokerServer.Program.Main() in f:\Projects\Visual Studio\PokerServer\PokerS
erver\Program.cs:line 23
It worked well on the old computer.
I have updated .NET (and all other updates under Windows Update as mentioned in another thread).
I have tried deactive and active "Code optimization" without any problems.
The directory is not the same as before, not sure if that can cause this problem?
I verify my code with peverify and if I understand it correctly everything looks good:
F:\Projects\Visual Studio\PokerServer\PokerServer\bin\Debug>peverify PokerServer
.exe /md /il
Microsoft (R) .NET Framework PE Verifier. Version 4.0.30319.33440
Copyright (c) Microsoft Corporation. All rights reserved.
All Classes and Methods in PokerServer.exe Verified.
Any help is highly appreciated!
Are you actually compiling the project on the new computer or just running the application?
If you're just running it, did you verify that the application assembly or assemblies are actually identical on both computers? I suggest, you first rule out the option, that something happened during the data transfer.
If you're compiling it, what are you compiling it with? VIsual Studio? Which version?
In any case, the error is not related to the file directory, the application is in. According to MSDN, the exception should only be thrown when the compiled application is invalid (i.e. in case of a bug in the compiler). You can find more info in this knowledge base article. Try running the PEVerify tool and rebuilding the application in debug configurtion as the article suggests.
I removed the old Nancy dependency and installed it again from Nuget and now it works.
Related
I have a problem only on a specific machine.
I have two programs with a reference to Sap.Data.Hana.v4.5.dll, the ADO.NET Provider for .NET 4.5 for HANA database.
When my programs instantiates a connection object with
dbConnection = new HanaConnection(...);
I get this error:
System.TypeInitializationException: The type initializer for 'Sap.Data.Hana.HanaConnection' threw an exception. ---> System.IO.FileNotFoundException: Cannot find libADONETHDB.dll.
at Sap.Data.Hana.HanaUnmanagedDll.SearchNativeDlls(String regKeyName)
at Sap.Data.Hana.HanaUnmanagedDll..ctor()
at Sap.Data.Hana.HanaUnmanagedDll.get_Instance()
at Sap.Data.Hana.HanaConnection..cctor()
--- End of inner exception stack trace ---
at [...my program calls...]
Why can't it find libADONETHDB.dll?
My applications are build one in 32-bit, the other in 64-bit.
On this machine I installed SAP HANA client 2.8.20.23662 (latest version) both 32-bit and 64-bit.
The file that cannot be found seems to exist:
You could use Process Monitor while running the relevant part of the program to see, which file is missing and the path it should be in. Exclude all other events than file events and filter out all SUCCESS messages.
Perhaps it is referenced relative to the calling DLL (where Sap.Data.Hana.HanaUnmanagedDll.SearchNativeDlls is defined).
My hipotesis is that GAC had been corrupted with version 1 of Sap.Data.Hana.v4.5.dll:
Probably in the past HANA Client version 1 had been installed and removed and uninstallation hadn't cleaned the GAC.
My program uses HANA Client of any version, works both with version 1 and 2. For some reason when they start they seem to take version 1 of Sap.Data.Hana.v4.5.dll in the GAC. Process Monitor (thanks #sc911) confirms it:
This .NET DLL then looks for some unmanaged DLLs in C:\Program Files (x86)\hdbclient. Version 1 seems to look for libADONETHDB.dll in root folder.
But currently in this machine in that folder we have HANA Client 2.x and its folder structure is quite different from that of version 1 (there is no libADONETHDB.dll in root folder).
Hence the error in this question.
All this is valid both for 32-bit and 64-bit HANA Client.
I solved renaming or deleting version 1 folder in C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Sap.Data.Hana.v4.5 (probably there are better ways for performing this cleanup).
I'm using python 3.5 installed in a virtual conda environment. The stackoverflow happens during a call to Py.Import:
dynamic np = Py.Import("numpy");
This was once working on my machine, but I decided to reinstall my Python environment. I set PythonEngine.PythonPath to the location of my virtual environment. My root Python install is also version 3.5. If I uninstall numpy, Py.Import fails expectedly due to the module not being found. If I reinstall numpy, I get a stackoverflow:
An unhandled exception of type 'System.StackOverflowException'
occurred in Python.Runtime.dll
Worker Thread Python.Runtime.dll!Python.Runtime.ImportHook.import Normal
[External Code]
The maximum number of stack frames supported by Visual Studio has been exceeded.
Importing built-in python modules works. I tried importing one of my own modules with a print statement at the first line, and the print statement gets called twice, so something is fishy. Any ideas why the stackoverflow exception is occurring?
Python 3.5.3
64-bit
numpy 1.13.1
VS2015
Pythonnet 2.30-py35-dotnet
After doing a lot of search, I still couldn't get the solution for the question.
I have a mdmp file. The call stack shows it is using mscorlib.ni.dll. So to get the function information, I need to get its pdb file.
The version of mscorlib.ni.dll is 2.0.50727.3655.
I believe it comes from .Net Framework 3.5.
Since mscorlib.ni.dll is the native optimized dll which is generated by ngen.exe, so I need to use ngen.exe createpdb to generate pdf for this dll.
ngen.exe createpdb "C:\Windows\assembly\...\mscorlib.ni.dll" "C:\SymbolCache"
Here is the result:
I can't find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v3.5"
I could find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v2", but it does not have createpdb option.
I could find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v4.0.30319" and it does support createpdb option, but it reports error.
Microsoft (R) CLR Native Image Generator - Version 4.0.30319.18408
Copyright (c) Microsoft Corporation. All rights reserved. Invalid
header found in native image
'C:\Windows\assembly\NativeImages_v2.0.507
7_64\mscorlib\5cd1c2848ff40eb0a8c149706ee394fa\mscorlib.ni.dll'.
Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL))
So I have no idea how to get the pdb for this mscorlib.ni.dll of Net Framework 3.5.
Any idea?
I had the same error message until I realized I call ngen.exe from the Framework64 folder. Apparently, the mscorlib.ni.dll was not 64-bit.
So I used the 32-bit version of ngen.exe from the folder C:\Windows\Microsoft.NET\Framework\v4.0.30319 and it successfully produced the PDB.
However, the path to your mscorlib.ni.dll includes ...\NativeImages_v2.0.507 7_64\..., which indicates it is 64-bit, so this might be a different issue.
Like the answer from Monsignor, for me the solution was to match the bit-ness (64-bit or 32-bit). My minidump was 64-bit so I had to go to the Framework64 folder and run ngen from there and it was fine. I originally got the same ngen error as described here (Invalid header found in native image...E_FAIL) because I was in the Framework folder instead of the Framework64 folder (facepalm).
However, even though the ngen command worked...the pdb that was generated ultimately was still not accepted by VS 2013 as a matching symbol file, in my scenario.
I've added a reference to the CUDAfy.NET library via NuGet.
<package id="CUDAfy.NET" version="1.12.4695.21111" targetFramework="net45" />
When I run my program, I hit a Win32Exception:
The system cannot find the file specified
This happens on the first actual line of the program:
CudafyModule km = CudafyTranslator.Cudafy();
There's no indication from the exception object as to what file they're attempting to load.
How can I get past this problem?
EDIT
I see the same exception when running the bundled examples from the Codeplex download in VS2010 using .NET 4.0.
The strack trace is:
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at Cudafy.CudafyModule.Compile(eGPUCompiler mode, Boolean deleteGeneratedCode)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Version cudaVersion, Boolean compile, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy()
Setting VS to break on thrown exceptions shows the ProcessStartInfo object at the top of the stack in the locals pane of the debugger.
The relevant properties are:
FileName = nvcc
Arguments = -m64 -arch=sm_12 "c:\<path>\CUDAFYSOURCETEMP.cu" -o "c:\<path>\CUDAFYSOURCETEMP.ptx" --ptx
Some information from this article explains that the CUDA Toolkit must be installed. Fair enough.
Ensure that the C++ compiler (cl.exe) is on the search path. This set-up of NVCC is actually the toughest stage of the whole process, so please persevere. Read any errors you get carefully - most likely they are related to not finding cl.exe or not having either 32-bit or 64-bit CUDA Toolkit.
That article discusses version 4 of the toolkit, but version 5 is available now and supported since CUDAfy v1.1.
Download from https://developer.nvidia.com/cuda-downloads
Note that the 64-bit version of the CUDA Toolkit 5.0 is a 942 MB download. If you install everything you'll need an additional 2815 MB. The toolkit alone requires 928 MB.
EDIT After installing the CUDA Toolkit 5.0, the program failed with a CudafyCompileException at the same source line:
Compilation error: nvcc : fatal error : Cannot find compiler 'cl.exe' in PATH
Searching my system drive:
C:\>dir /s cl.exe
This shows many different versions of the compiler/linker, both from VS 10.0 and 11.0. Apparently only cl.exe versions 9 and 10 are supported, so I opted for the VS10.0 amd64 version, I included the following in my PATH environment variable:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64
Your path may be different, depending upon your CPU. I recommend running the search to see your options.
Note that you will have to restart VS after changing the PATH environment variable if you already have it open.
After taking these steps, my basic program ran successfully.
This may also happen if you had at some point installed CUDA Toolkit v7.5, but realized that the most recent version of CUDAfy supports CUDA 7.0.
On uninstalling CUDA 7.5 from the control panel, some files/folders may still remain. You should delete these manually. You may use CUDAfyViewer to see which version of CUDA Toolkit is being accessed.
I have some C# code written on machine #1 using Visual C# Express 2010. The code is dependent on some COM objects that are registered DLLs. It compiles and runs fine on machine #1. The COM objects are installed from a program called BostonWorkstation, which is installed on machines #1 and #2.
Machine 1:
Code written on.
Visual C# 2010 Express installed.
The "BWS" DLLs are registered.
The program runs just fine.
Has .NET versions: v4.0, v4, v3.5, v3.0, v2.0
32bit
Machine 2:
The "BWS" DLLs are registered.
The program errors with System.InvalidCastException (below).
Visual C# 2010 Express not installed.
Has .NET versions: v4, v3.5, v3.0, v2.0, v1.1
32bit
Machine 3:
The "BWS" DLLs are not registered.
Visual C# 2010 Express installed.
The program errors (as expected) with: System.Runtime.InteropServices.COMException (...): Retrieving the COM class factory for component with CLSID {...} failed due to the following error: 80040154 Class not registered (...)
32bit
When I try to run that program (compiled on machine 1) on machine #2 which also has the same exact registered DLLs, but the program fails to run. I also tried running it on machine #3, which doesn't even have the DLLs and that gets a different error as expected.
The runtime error on machine 2:
1 Unable to load BostonWorkstation, error: System.InvalidCastException: Unable to cast COM object of type 'System.__ComObject' to interface type 'BostonWorkStation70.BostonWorkStation'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{8C8144EF-ADB7-48FD-A5BB-6E55B8382B3E}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
at TestBWS.LoginForm() in C:\Documents and Settings\user\My Documents\Visual Studio 2010\Projects\project1\TestBWS\CodeFile1.cs:line 67
(The Visual Studio folder reference is just the compile time path)
Checking the registry on machine 1 I found this:
HKEY_CLASSES_ROOT\Interface{8C8144EF-ADB7-48FD-A5BB-6E55B8382B3E}
with a default REG_SZ value of BostonWorkStation
The code:
using BostonWorkStation70; //line 1
...
try
{
bwsLogin = new BostonWorkStation(); //line 67
}
catch (Exception e)
{
Console.WriteLine("1 Unable to load BostonWorkstation, error: " + e);
System.Console.ReadLine(); //pause the debug window
return false;
}
I have tried running ProcMon to compare the machines Process logs, but there are thousands of entries for just this program and I'm not seeing any missing references offhand. I ran a compare, but a successful Process log has 5x as many lines.
From what I understand, running the program on machine 2 has it creating the BWS object as a generic System.__ComObject (instead of BostonWorkStation70.BostonWorkStation) and I don't know why. The DLLs etc are definitely correct on machine 2, otherwise I'd be getting that Class not registered error on runtime.
Why will the compiled program not run on machine 2? All the dependent COMs/DLLs are on it.
if that error message is coming from machine #2, the one you said "Visual C# 2010 Express not installed."
why is it running from the default visual studio projects folder?
C:\Documents and Settings\user\My Documents\Visual Studio 2010\Projects\project1\TestBWS\CodeFile1.cs:line 67
You may have other problems....
Have you registered your COM object class from the library using regsvr32.exe on second machine?
To check that I'd search the registry on first and second machines looking for all possible {8C8144EF-ADB7-48FD-A5BB-6E55B8382B3E} string entries. If search results are different then it's probably the case.
If the BostonWorkstation components are unmanaged - open them up in dependency walker to make sure that all their dependent dlls are present.
Odds are they are unmanaged components and make use of the MSVCRT 10. In which case you will need to install the VS 2010 CRT on machine 2.