I created Net 4.5 Windows service which is used my.dll. My.dll is compiled with CLR support. I created msi file using Project Setup project from Visual Studio 2013. I set vsdraCOM option for my.dll file to provide auto registering of library.
When I install and start service under development machine (with Visual studio 2013) using sc command the service starts well. But then I use msi file for installing under "clear" machine and then try to start I get an error: System.IO.FileNotFoundException: Could not load file or assembly my.dll
I tried to register dll by hand using regsvr32 my.dll but got an error: Could not load module "\mydll". Could not find path .` (the error message was translated from my native language).
I also used ProcMon to analyze what was the problem but didn't see any faults.
I tried to put dll file into System32 directory but it didn't solve the problem.
I installed redistributable package and add the following dlls in System32 directory: msvcp120d.dll, msvcr120d.dll, vccorlib120d.dll from c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\Debug_NonRedist\x64\Microsoft.VC120.DebugCRT\
The problem is solved
Related
I'm working on VS2019 and CR13 SP27. I installed my program on another computer and installed CR27 runtime. When I run my new program all is good and reports show without error.
But when I want to run my another program that I ever installed (my old program working on VS2017 and CR13 SP21 and installed CR21 runtime in client computer), it gives an error:
System.IO.FileNotFoundException: Could not load file or assembly
'CrystalDecisions.Web, Version=13.0.3500.0, Culture=neutral,
PublicKeyToken=692fbea5521e1304' or one of its dependencies. The
system cannot find the file specified.
I wonder if CR13 SP27 Runtime does not support CR13 SP21 runtime?
Before I install SP27 runtime I uninstalled SP21 runtime. Is it related?
How to make all my programs work well with CR report difference version on another computer?
I've just installed SQL Developer 4.1.1 64-bit on a Windows Vista machine, in directory c:\sqldeveloper.
My Java installation is in c:\program files\java and I have two sub- directories:
c:\program files\java\jdk1.8.0_31
c:\program files\java\jdk1.8.0_25
I have modified the jdf.conf and sqldeveloper.conf files in the
c/sqldeveloper/sqldeveloper/bin directory. jdf.conf was empty and I added the following line:
SetJavaHome
c:\program files\java\jdk1.8.0_31
sqldeveloper.conf:
#SetJavaHome ../../jdk <===== This is what is was
SetJavaHome c:/program files/java/jdk1.8.0_31 <======= I changed it to this
I even moved the missing file "msvcr100.dll" it was asking for to the c:/sqldeveloper/sqldeveloper/bin directory.
I got the following error messages:
This application has failed to start because msvcr100.dll was not found.
Re-installing this application may fix this problem
Unable to launch the java virtual machine located at path
c:\sqldeveloper\jdk\jre\bin\server\jvm.dll
The file msvcr100.dll is in the Java directory c:/program files/java/jdk1.8.0_31/bin.
The file jvm.dll is in the Java directory
c:/program files/java/jdk1.8.0_31/bin/jre/bin/server.
I modified product.conf:
#SetJavaHome /path/jdk <===== This is what it was
SetJavaHome C:/Program Files/Java/jdk1.8.0_31 <====== This is what I changed it to
I have a copy of msvcr100.dll in sqldeveloper/sqldeveloper/bin folder and in the c:/program files/java/jdk1.8.0_31/bin folder.
To run SQL Developer I click on sqldeveloper.exe in the c:/sqldeveloper/sqldeveloper/bin directory.
Is I am running it on the correct way?
I ran in to the same problem myself, trying to run SQL Developer 4.1.1 64-bit with JDK on a Windows Server 2008. I've installed SQL Developer many times over the years from 1.x to 4.1.1 and never encountered this until now.
I solved it by copying the MSVCR100.dll file from sqldeveloper\jdk\jre\bin to the sqldeveloper\sqldeveloper\bin folder.
Update 3/18/2017:
In downloading the latest version from Oracle's website, I found this in the installation notes which confirms and explains the issue:
Note: the Windows EXE requires a MSVCR100.dll to run. Most computers will already have this file and in the Windows PATH. However, if the first copy of the file found by the EXE is a 32-bit copy of the DLL, then SQL Developer will fail to start. You can fix this by copying a 64-bit version of the DLL into the BIN directory or updating your OS PATH such that a 64 bit copy of the DLL is found first.
Only create the directory /sqldeveloper/jdk/bin and copy The file msvcr100.dll is in the directory.
Then /bin don't exist is in the /sqldeveloper/jdk
I have faced this similar issue on my local system.
I have solved this issue by copying bin directory from insatallation_directory/jdk/jre to insatallation_directory/jdk/
You need to copy the msvcr100.dll file from sqldeveloper/jdk/jre/bin/msvcr100.dll to sqldeveloper/sqldeveloper/bin/. Then just open SQL Developer again.
You only need to create the directory \bin in sqldeveloper \sqldeveloper\jdk\bin and copy the msvcr100.dll file in this new directory.
Got the same issue with newest versions.
Interestingly enough, msvcr100.dll is present in JRE 1.8.0_251, but not in JRE included in JDK 1.8.0_261.
Even though I run SQL Developer with included JDK, it tried to use my installed JRE 1.8.0_261.
Resolution was simply to copy missing msvcr100.dll from any other place (like jre1.8.0_251\bin or maybe even Windows/System32) to the JRE used by SQL Developer. In my case to jdk1.8.0_261\jre\bin.
I want to load MSEC.dll in windbg Version 6.12.0002.633 X86.
when I use the command !load MSEC.dll
it says:
The call to LoadLibrary(MSEC.dll) failed, Win32 error 0n127
"The specified procedure could not be found."
Please check your debugger configuration and/or network access.
I changed the version to 6.11 and I also installed visual studio 12 run time with version 12 but it doesn't work!
Is there any way to handle this issue?
When we extract Bang Exploitable (!Exploitable) it creates 2 Folders:
x64
x86
Open the folder as per your Project Bit Size. Now inside that folder, you will get 2 another folders:
Release
Debug
Copy the files from release folder to the folder that contains the executable of windbg.
Sometimes you may also need to change the version of windbg for making it compatible with bang exploitable.
Download
http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi
I had the same issue (winxp sp3, windbg 6.12..., !exploitable 1.6). Installing CRT 11 runtime did not work for me. So, the only solution I've found is to use the older version of !exploitable (1.0.6), you can download it here: https://msecdbg.codeplex.com/releases/view/28935
I spent all morning trying to figure this out.
Codeplex was retired in 2021 and this assembly appears to be abandoned by MS so it's difficult to find information.
The site I'm linking to below indicates that you need the Visual C++ 2012 redistributable installed on the target machine to remove this issue.
The same site also statically linked the required files in the source code and rebuilt with VS2017. I downloaded the altered DLL and am now able to load msec.dll with the full path to the assembly in the command.
https://blog.didierstevens.com/2018/07/17/exploitable-crash-analyzer-statically-linked-crt/
I was troubleshooting an issue on a customer's workstation and found that, to my surprise, adodb.dll was nowhere to be found on the customer's workstation.
Typically, I see the file in C:\Program Files\Microsoft.NET\Primary Interop Assemblies folder.
Is this file distributed with the .NET framework or not?
Judging by MSDN, that file is written during a Visual Studio install.
Note Visual Studio.NET provides a Primary Interop Assembly (PIA) for ADO in the "Program Files\Microsoft.NET\Primary Interop Assemblies" directory in the file adodb.dll. If you have a copy of Visual Studio.NET installed, it is recommended that you use this file (adodb.dll) as opposed to importing your own using the Type Library Importer (tlbimp.exe).
I have this file on computers with VS installed, and don't have it on computers without VS installed. It looks like it should be pretty easy to generate your own with TlbImp.
We moved our Visual C++ 2003 solution to Visual 2005 and now we have problems deploying to clean XP machines.
Our solution has a DLL project and a command line executable which uses this DLL. Both projects create and embed manifest files.
Our installer also copies the VC8 CRT runtimes from the C:\Programme\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT\ to the install dir.
When we install on a clean Windows XP, we see the error message "Application has failed to start ... application configuration is incorrect."
Putting the exe in Depends.exe, says:
Error: The Side-by-Side configuration information for "c:\program files\MySoftware\vc8\BENCHMARK.EXE" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Error: The Side-by-Side configuration information for "c:\program files\MySoftware\vc8\MYLIB-VC8.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
Event viewer logs:
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system.
Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error message: The referenced assembly is not installed on your system.
Generate Activation Context failed for C:\Program Files\MySoftware\vc8\Benchmark.exe. Reference error message: The operation completed successfully.
I've read copying the msvcp80.dll,msvcr80.dll,msvcm80.dll and Microsoft.VC80.CRT.manifest to application folder is sufficient.
What am I doing wrong ?
Copying the CRT dlls around is not recommended. As Vinay says you should use the correct merge modules.
You can also use the redist install exe's if merge modules don't work with your installer technology:
VS2005 CRT
VS2005 SP1 CRT
As a last resort try copying the entire 'Microsoft.VC80.CRT' directory to your programs exe directory (not the contents, the actual directory).
You don't really need the Microsoft's VC80 C Run-Time Library. It's a mess.
Instead, relink your program with /MT option, which static links the c run-time library(libcmt.lib) or C++ Standard Library. To set this via the project properties, go to
C/C++ -> Code Generation -> Runtime Library: Multi-threaded (/MT)
If it doesn't compile, you may want to add this option as well (/NODEFAULTLIB:)
Linker -> Input -> Ignore Specific Library: msvcrt.lib
See the link options from http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
Select Visual Studio 2005 Merge modules in the installer.
This can also occur if you have built the exe/dll using visual studio which has service pack installed.
I had this problem as well. I was appalled at Microsoft for doing this to us.
(I used VC6 to build a particular project and then when I also installed 2003 and 2005 on the build machine it caused my VC6 build to have issues. (I was not checking installs on a pristine machine) Apparently the linker/compiler had no idea what it was doing so it caused problems with my distributable. I then had to add a HUGE redist install file to my 120k exe app. Freakin' microsoft.
MS has screwed this up a few times in the past.
http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en