Using VS2022, I created a c++ (ver 14) console app. This app needs to have no UI or console window, which is working. In order to implement no UI or console window, I changed the default 'Main' to
int WINAPI wWinMain(HINSTANCE hInst,HINSTANCE hPrevInst,LPTSTR lpCmdLine, int cmdShow) However, I'm having issues when switching to Release mode, which I could use some assistance with.
The first problem is a link error, when I change to Release mode, LNK2001 'unresolved external symbol _main. A google search I found suggested adding back the default int main(int argc, char argv)**, in addition to the wWinMain. This did allow for a successful compile/build. The issue is, in debug mode, the entry point is wWinMain, in Release mode, the entry point is main(...). I'm not sure why this is occurring or how to go about fixing it. Help is appreciated.
I'm unable to run the app in Release mode but I am in Debug mode.
As comments pointed out, /SUBSYSTEM specifies the Windows subsystem targeted by the executable. You can set this linker option in the Visual Studio development environment.
The /SUBSYSTEM option specifies the environment for the executable.
The choice of subsystem affects the entry point symbol (or entry point
function) that the linker will select.
Related
I am learning about reverse engineering on windows. I was following Reverse Engineering and Function Calling by Address. I did not download those source demo. I just write down a little c++ console and debug it my self with Ollydbg or xdbg64. Just for to know how windows' stack work.
#include <Windows.h>
#include <stdio.h>
void __cdecl mySecretFunction(int * param1, const char *param2,
DWORD param3, BYTE param4) {
// Do somethng
}
int main() {
// Do somethng and call mySmySecretFunction()
}
I have enable /DEBUG and choose Debug on Configuration on App properties page.
I ran App.exe and it works well. I debug with Ollydbg, it can run normally, but both disassembly and symbol of the exe are gone or missing. So I cant debug it.
So what I must to do/configurate in visual studio 2017 so I can debug my simple c++ console with external debugger like Ollydbg or x64dbg ?
The following steps worked for me with Visual Studio 2017:
Create an empty C++ project.
Add the source code you provided.
Go to your project properties, select Debugging.
Change Command to c:\x64dbg\release\x96dbg.exe (notice the 96), this starts x32dbg.exe or x64dbg.exe depending on your executable architecture.
Change Command Arguments to "$(ProjectPath)" arg1 arg2 where $(ProjectPath) is the previous contents of Command and arg1 arg2 is the previous content of Command Arguments.
Debug the executable by launching the program without debugging (Ctrl+F5). If you launch the debugger like usual you will be debugging x64dbg itself, which is probably not what you want.
There is no real integration with x64dbg and Visual Studio, this simply starts x64dbg with the right arguments to debug your application from Visual Studio and you would be much better served by loading the application in x64dbg once and then manually loading it for low-level debugging.
don't enable debug mode if you want to debug in olly-DBG. debug mode is for debugging in visual studio. in this mode you can see variables name and run program line by line. the line and varietals name have no meaning in olly-DBG. it is better that don't compile in debug mode.
you can't see your code beacuase you don't pause your program at winmain.
Go to option > Debugging option > Events and select Make first pause at:>WinMain (if location is known)
hope it help you.
I know this question is old. Anyways this's my own answer to your question.
Using the visual studio, you can integrate your debugger x64dbg to your project or current project like this.
You need to locate the part to your x64dbg program, either x64 or x86 version depending on the bit of the application you want to debug or build etc.
Provide an argument for this current project of yours. In this case, either by the full part to the executable of your project or better still in a more portable fashion, use the Microsoft macros as shown in the picture below.
And although you can provide the target initial directory for the program, but is optional. Then whenever you want to debug your application, all you need to do is just click the button and the debugger will start with the application.
I am having issues registering and using a dynamic library under Windows 7 x64, the 64-bit version of dll compiles but the compiler log outputs:
Error MSB3073: The command "RegSvr32 /S "...\x64\Debug\xxxxx.dll" exited with code 3.
But, when I build 32-bit version of the dll, compiler log outputs the RegSvr32 command was successful.
I already set the Linker >> General >> Register Output to No in both x86 and x64 build configurations.
I tried running 64-bit and 32-bit version of RegSvr32 (without silent mode) with 64-bit dll, but it responds with the following error:
The module "xxxxx.dll" failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found.
I checked it using dependency walker and it reported more than 100 dlls are missing so, I cannot show them here. Some of them are:
API-MS-WIN-CORE-COM-L1-1-1.DLL
API-MS-WIN-CORE-DATETIME-L1-1-1.DLL
API-MS-WIN-CORE-DEBUG-L1-1-1.DLL
API-MS-WIN-CORE-ERRORHANDLING-L1-1-1.DLL
API-MS-WIN-CORE-FILE-L1-2-1.DLL
...
WLANUTIL.DLL
WLDAP32.DLL
WTSAPI32.DLL
XMLLITE.DLL
Dependency Walker with opened dll:
I am wondering what the reason for only 64-bit version of dll cannot register using RegSvr32.
Any help is greatly appreciated to resolve this issue.
UPDATE 1
Trying to running the application with this dynamic library results in the following error (both 32-bit and 64-bit versions) :
The program can't start because api-ms-win-core-errorhandling-l1-1-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
All redistributable packages currently I have installed:
Is there any visual c++ redistributables I have to install to solve this?
UPDATE 2
I found More information on api-ms-win-core-errorhandling-l1-1-1.dll here and tried linking WindowsApp.lib with this dynamic library, but it even didn't resolve the issue.
UPDATE 3
I ran system file checker and it gave me following output as I thought it should:
Windows Resource Protection did not find any integrity violations.
Go into the project properties of the DLL you're trying to register
Go to Configuration Properties >> Debugging
Under "Command", click on the little down arrow and choose "regsvr32.exe"
Under "Command Arguments" type "$(TargetName)"
Put a breakpoint somewhere in your DLLMain
Now Debug the DLL (Right click on the dll project in solution explorer and choose "Debug")
If you get to your DLL main, you can debug from there until it fails. If you do not, you should take a look at the output window to see any relevant messages. You might need to change your output window filters too. Right Click on the output window and check all categories of messages to be sure it gives you everything and then debug again.
That should at least tell you where you are failing. Look for module load failures and the like
Edited to add - you might try just changing the build step by removing the "/S". That is "Silent" mode and in this case you want to see the messages.
I finally solved the problem by removing mincore.lib from linked .lib files in both x86 and x64 versions of project, which I recently linked to use GetFileVersionInfoSize API function.
I'm developing my first application using GLUI and I'm having some problems. I'm using Visual Studio 2010 on a Windows 7 machine and using glui-2.35. My application runs fine when built in debug mode but crashes with a runtime error when built in release mode. From the debugger the error is from the last statement in this function from glui.cpp:
void GLUI_Master_Object::set_glutReshapeFunc(void (*f)(int width, int height))
{
glutReshapeFunc( glui_reshape_func );
add_cb_to_glut_window( glutGetWindow(), GLUI_GLUT_RESHAPE, (void*) f);
}
I'm not sure why the release build crashes; any suggestions would be greatly appreciated.
I'm not an expert in MSVC++ debug and release mode but I've been looking for some information, and in this website, some users talk about it.
One of them (#mcdeeiis), in this page, says:
...
In a debug build the complete symbolic debug information is emitted to help while debugging applications and also the code optimization is not taken into account.
While in release build the symbolic debug info is not emitted and the code execution is optimized.
Also, because the symbolic info is not emitted in a release build, the size of the final executable is lesser than a debug executable.
One can expect to see funny errors in release builds due to compiler optimizations or differences in memory layout or initialization. These are usually referred to as Release...
Anyway, check sure the libraries that GLUI or your project depends on, have been compiled with release mode too. It might cause problems.
I keep getting this error message as a result after every Debug run I have done on any of my projects in VS2003.
I have browsed around many forums and they all provide an answer that does not fit to the actual problem.
LINK : fatal error LNK1201: error writing to program database 'd:\Coding\Flyff\Projects\GUI System 20110721\Debug\GUI System 20110721.pdb'; check for insufficient disk space, invalid path, or insufficient privilege
I'm using Windows 7 Ultimate x64 with Visual Studio 2003 .NET (service pack VS7.1sp1-KB918007-X86.exe).
What I have tried already:
Run in compatible mode for several other operative systems and service packs.
Set project folders write permission to full.
Run Visual Studio as Administrator.
Edited Debug Information Format to several other formats.
To reproduce this bug, you must have Windows 7 x64 (probably Ultimate).
Visual Studio 2003 (with VS7.1sp1-KB918007-X86.exe update).
I have over 150 GB space so it has nothing to do with that.
Visual Studio simple locks the PDB file when debugging, and after debug it cannot unlock it.
You must also run a code piece that is running for a few seconds, such as this:
int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
Sleep( 5000 );
MessageBox( NULL, "Test", "", 0 );
return 0;
}
Hope anyone have a solution, as I'm currently required to use this environment configuration.
Cheers, Nicco.
I have finally found a workaround solution for this problem that has been plaguing me for quite sometime:
1) Download and install LockHunter (free utility to unlock locked files):
http://lockhunter.com/download.htm
2) Add the install directory of LockHunter to your environment variable "path" to avoid annoying administrator privilege popups every time you run the utility. For me (using x64 version) it was:
"C:\Program Files\LockHunter"
3) Add the following pre-build event to your Visual Studio project that is experiencing the issue:
"LockHunter.exe /silent /unlock $(TargetDir)$(TargetName).pdb"
The only time I have encountered this issue with VS2003 is when it crashes during a debug session. Usually the problem can be remedied by restarting VS. If that doesn't work you have to restart the debugger service and in some cases Windows.
You can try adding the following to command line of the pre-build event
net stop "Machine Debug Manager"
net start "Machine Debug Manager"
Since either VS or the debug manager is keeping the file locked I fear this problem is caused by a much deeper issue. There is a good chance that either a problem exists in your VS installation or there is another service or application causing the debug manager and/or VS to behave badly.
I encounter this error with VS2010 and tried fixing it using methods suggested in forums but they never worked for me. At the end I exited VS2010 and restarted as Admin and that did the trick!
I have the same inssue with winXP SP3 and VS C++ 2010 Express, and i solved changing the MyProject folder Access Permissions, uncheking "read-only" and apply to all folders, subfolders and files.
Non of the above answer work in my case, But finally I found my Solution.
When scale of the project grows and size of the ".pdb" file exceed 300MB, the error accrued.
I change debugging info properties in my project and successfully compile it.
You just need to change "Debug information format" in your project to "C7 compatible (/Z7)" in the following path.
Configuration properties >> C/C++ >> General >> Debug Information
Format
Had similar problem on Windows 10. This answer provides a solution using a tool called FreePDB.
Guys that is code copied from a book (Programming Windows 5th edition):
#include <windows.h>
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
MessageBox (NULL, TEXT ("Hello, Windows 98!"), TEXT ("HelloMsg"), 0) ;
return 0 ;
}
Link to the topic in which this book is recommended.
Can't compile it with VS2010. What am I doing wrong?
Error 1 error LNK2001: unresolved external symbol _WinMainCRTStartup
Thanks.
It will depend on how you set up the project. In VS2010, if I create a new project via File->New->Project, Visual C++, Empty Project, then add a new C++ file, and copy your code in, it compiles and runs just fine.
If you've created a different type of project, it may be using different link libraries. Try right-clicking on your project in Solution Explorer, going to Properties->Linker->System, and setting SubSystem to "Windows (/SUBSYSTEM:WINDOWS)
The Win32 APIs are old, but for the most part are perfectly usable if you want to do native Windows programming. Windows has done a great deal of work to ensure that as long as you've followed the documentation, old APIs will not change. You can still compile 16-bit Windows 3.1 code from 1992 and run it on 32-bit Windows 7.
Edit:
It could also be that in Properties->C/C++->Advanced, you have Omit Default Library Name set to "Yes", you probably want it set to "No"
Or also Properties->Linker->Input->Ignore Default Libs should be set to No.
You need to set the project's linker settings to create a Windows GUI program rather than a console program:
"Linker/System/SubSystem" should be set to "Windows (/SUBSYSTEM:WINDOWS)"
Usually this setting gets set properly when you create the project and choose a Windows GUI Application template. Unfortunately, if the project is set to the incorrect application type, the setting is a bit buried (it took me bit of digging to find it).
Make sure you have actually added the source file to the project. This worked for me.