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.
Related
I'm currently trying to learn Assembly for x64 Windows. I tried the example code from this Intel website,
but whenever I try to compile it with the command given in the document:
ml64 hello.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Start
I always get an
LNK1104 error
I know that it means the compiler can't find the library file, I googled the problem and quickly found that I need Visual Studio with Windows SDK, which I downloaded and installed. But still can't find a kernel32.lib or user32.lib in any files other than the Windows system files.
I tried everything and I simply can't fix it. I hope someone could help figure this out.
There is a well-known MASM32 SDK available created by hutch--. This package contains the requested libraries in a (legacy) 32-bit version.
But there is also a 64-bit update of that famous package by hutch--:
Current build of the 64 bit MASM SDK.
It should contain the .inc and .lib files you need and more...
This is the current build of the 64 bit MASM SDK. This one is a lot closer to complete and with the correct Microsoft binaries added to it, it is capable of building a wide array of application types. It can be use in 2 different ways, it should be unzipped from the root directory of the partition that it is being installed on. You can either manually add it to an installation of the MASM32 SDK OR you can install it on a partition that does not have MASM32 on it and simply rename the buildx64 directory to MASM32. Installing it on another partition is the preferred technique as QE has its menus and accessories set up for building 64 bit code.
You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.
In the "buildx64" directory is a batch file called "makeall.bat". This must be run to build all of the libraries and include files.
They are the gold standard of Windows assembly developing.
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
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 am using Microsoft enterprise library in one of my projects. I need to strong name one of the dlls which is Microsoft.Practices.EnterpriseLibrary.Common. But it is not working.
When I decompile using ILDASM, it generates 3 files.
IL file
.RESOURCES file
Common resource script file
How do I compile it with the key file. Which ILASM command should I use?
The dll's are distributed from the original install in a few different modes. One set of files is already signed, so you need to find that set and use the files from that set.
When you install the EntLib package, you get the compiled binaries (some are signed) AND you get the source code, which compiles the source-code and creates the dlls (not signed).
My guess is that you are using the non-signed (compiled from the source code on your local machine) files, instead of the signed ones.
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