When changing a project from targeting .NET 4 to .NET 4.5 I get the following added to the project file for each build configuration:
<Prefer32Bit>false</Prefer32Bit>
What does this mean? The only documentation I could find on MSDN wasn't too clear.
Sets the 32BITPREFERRED flag. The app runs as a 32-bit process even on
64-bit platforms. Set this flag only on EXE files. If the flag is set
on a DLL, the DLL fails to load in 64-bit processes, and a
BadImageFormatException exception is thrown. An EXE file with this
flag can be loaded into a 64-bit process. New in the .NET Framework
4.5.
From the Corflags documentation
http://msdn.microsoft.com/en-us/library/ms164699.aspx
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 have a simulink model (2016b with MC 2013 C/C++ and Mingw-64 compilers) that I'd like to generate a standalone executable for windows-64 bit.
I was able to run the grt executable but due to the fact that I need to read a mat file runtime as opposed to compile time, I am using rsim code generation for this purpose, however the executable that gets generated appears to need quite a bit of .dll, I provided the dll it was asking for however, the application still unable to run. This is the error that results
The application was unable to start correctly 0xc000007b. Click OK to
close the application
What am I missing ?
Your main program is compiled for x64 (64-bit) target, but the dll you provided is compiled for x86 (32-bit) target. Or vice versa.
If it is Mingw-64 stuff, you should be able to obtain all (or most) of them by using the official online installer. Link is here.
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/
Under Windows 7 x64, when I try to profile an x86 executable with the latest version of Dependency Walker (2.2.6000) the profiling process always hangs at a certain point. Most of the time the last DLL that is loaded is c:\windows\syswow64\URLMON.DLL, so it seems that something inside that DLL is causing a problem. Profiling the same executable on Windows 7 x86 works flawlessly.
I have googled quite extensively, but couldn't come up with a solution to the problem. One suggestion that I found was to uninstall IE 8 or IE 9 and replace it with IE 7, but this doesn't really help. The only effect that I can observe is that with IE 7 the profiling process hangs at a different DLL (iertutil.dll, if I remember correctly, also from the system's syswow64 folder).
So my question is: How can I get Dependency Walker to profile x86 applications on x64 Windows 7? Of course, it would also be nice to know why the problem exists in the first place :-)
Some final notes:
I am using the x86 version of Dependency Walker because I want to profile an x86 executable
Running Dependency Walker as administrator does not help
All profiling options marked as "may fail on WOW64" are disabled
The executable I am currently using as a test case to reproduce the problem is the Sumatra PDF viewer (download link) because it is a simple .exe that does not need installation
Updated instruction based on #Stone Free's comments
The download link you need has changed to:
https://www.microsoft.com/en-us/download/details.aspx?id=42273
Go down to the 2. Install WDK 10 section and select the download:
Locate and run the Wdk setup (wdksetup.exe) from stage 2, then choose the download option rather than install.
Once completed locate and run DownloadLocation\Windows Kits\10\WDK\Installers>"Windows Driver Kit-x86_en-us.msi"
Then you will find Dependency Walker at:
C:\Program Files (x86)\Windows Kits\10\Tools\x64\depends.exe for the 64 bit version
C:\Program Files (x86)\Windows Kits\10\Tools\x86\depends.exe for the 32 bit version
Which is Dependency Walker version 2.2.10011 built 2015-10-29
A handy tool is to use https://github.com/juntalis/depends-launcher which is a simple launcher for Dependency Walker that determines the platform (x86|x64|ia64) of an windows image (dll, exe, etc) and launches the appropriate version of depends.exe to view its dependencies. It's main purpose is for use in a context menu entry to easily view an image's dependencies.
The latest currently known version of Dependency Walker seems to be the 2.2.10011 from 2015-10-29 (links below).
It was deployed with some Windows Development Kit for Windows 10 but the version that it contained is not available anymore from the Microsoft Pages and all the newer Versions does not contain it anymore for unknown reason.
Maybe because also the latest versions have some Problems with the Dynamic-Link Library Redirection or other performance issues. (Using dependency walker under windows 10 seems to be a lot more slow and cumbersome than at previous windows versions - but still great tool for the job)
Following Versions are available:
2.2.10011 (2015-10-29)
unofficial available from this development blog - download at own risk
https://zzz.buzz/2017/05/18/download-dependency-walker/
2.2.9600 (2013-08-22)
available through the WDK 8.1
https://www.microsoft.com/en-us/download/details.aspx?id=42273
after installation present in C:\Program Files (x86)\Windows Kits\10\Tools\[Arch]\depends.exe
2.2.6000 (2006-10-28)
available from official authors website
http://www.dependencywalker.com/
Potential replacement:
For simple tasks the Github project lucasg/Dependencies may be worth to be checked out. But it currently does not support profiling a running app to debug broken runtime dependencies as depends.exe can do.
I've had to switch to using a GitHub project: Dependencies.
As of Windows 10 1809 (10.0.17763) I'm unable to run even depends.exe version 2.2.10011 included in 10.0.10586.0 WDK.
I ran into the same problem and I discovered it is fixed in the latest version of Dependency Walker. I compared 2.2.6000 versus 2.2.8288 and the problem exists in the former but not the latter. However, you will probably have to wait for the Windows 8 WDK to be released to the public in order to get the latest version.
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