I just got a new 64-bit computer with the characteristics in the title above and am trying to run a simple OpenGL program with only glutInit() and return 0 in main() . It builds but running under Debug opens a window with a black screen and then another popup window which says "The application was unable to start correctly (0xc000007b). Click OK to close the application." I've rechecked the placing of the .h, .lib and .dll files and they match suggestions I've found online. I think my project settings are correct or it wouldn't have built. What did I forget to do?
I have written a small getting-started program for OpenGL 3.2 (or later) using Visual Studio 2010 and FreeGlut / GLEW.
https://github.com/mortennobel/OpenGL_3.2_VS_2010_freeglut
One important points to notice is to set glewExperimental = GL_TRUE; (otherwise the program can crash on some OpenGL drivers).
Related
This is from Visual Studio Community 2022 64-bit 17.1.1, "Current."
The binary to be debugged was compiled on Windows 11 with the same IDE, but I'm running it on Windows 10 Pro. Once it starts, I'm trying to attach the debugger.
The same file system contains all exe, lib, dll, obj, and source, all in the same places and full paths, as it's mounted in the same position on both computers (T:).
Attachment type is "Automatic." I'm doing Debug->Attach to Process, and clicking on a PID.
The same workflow succeeds on connecting the debugger on the same IDE on the Windows 11 box where the exe was compiled.
All processes belong to the same user (me).
Googling is finding nothing at all except red herrings about remote debugging (I'm trying to debug on the computer running the binary) and permissions.
OK, I'm not sure if this answer will help others, but on Windows 11, when I select the binary in question, the "Attach to:" menu comes up as "Native Code" automatically. On Windows 10, the same Visual C++ release, attaching to the exact same binary, for some reason is detecting it as Python. Manually setting the Code Type to "Debug these code types:"-->Native allowed the debugger to attach correctly.
I have created a simple plane MFC application using VS 2015 and if i try to run the exe in another windows 10 machine where VC++ 2015 redistributables are present, then exe is not getting launch.
If i change it to Unicode then it works fine in another machine where VC++ 2015 redistributables are present, its failing specific MBCS.
in the Event viewer i noticed below error,
"Application popup: MFCApplication2.exe - System Error : The code execution cannot proceed because mfc140.dll was not found. Reinstalling the program may fix this problem."
i checked the mfc140.dll its present in system 32 folder, also i placed the same dll at the exe level and run. again new error noticed in event viewer like
Application popup: MFCApplication2.exe - Application Error : The application was unable to start correctly (0xc000007b). Click OK to close the application.
For testing purpose, i made the application as static linkage, in that case its working fine in another machine, but for dynamic linkage the exe is not launching in another machine.
Here are the list of VC++ Redistributes present in the windows 10 machine.
How we can fix the issue?
Edit,
Here i found MBCS installer for 2013 (http://go.microsoft.com/?linkid=9832071). But if i run i'm seeing below error, why we require VS for running MBCS i'm not understanding.
thanks
When building and running an OpenGL Solution, it opens the OpenGl window and a terminal. My question is how do I set it so that this terminal appear in my debug build but not my final build?
I'm using Visual Studio 2017.
Set the Debug configuration to use the CONSOLE subsystem and WINDOWS for Release.
Don't forget to adapt your entry-point (main() vs WinMain()) if your application framework (if any) doesn't handle that internally. SDL2 for example handles that for you via some #ifdef logic.
I am using Visual Studio Graphics Debugger in VS2017 and only shows MS apps. I even selected it in the edit and added it and GTAV is in running state but can't be selected:
Update: (Regarding Gareth's answer):
I already showed my directX control panel, there's nothing further I could do:
Also, in other debug options, after clicking, it shows the same thing as the first window:
It looks like the limitation is not related to the debug targets all being MS, as Candy Crush is by King.
What they do seem to have in common is that they've all been installed the same way, probably through the Windows Store as App Packages, while GTA was installed with an executable installer.
Consider looking in the "Other Debug Targets" or "Attach to Process" menus for attaching to non-App Packages. The DirectX Control Panel menu item may also be worth reviewing.
Debug Installed App Package only works on Universal Windows Platform (UWP) apps. GTA V is a Win32 desktop app, so it would not be expected to show up in that menu.
You can run VSGS on a EXE by opening it with Visual Studio, and then using Debug / Graphics -> Start Graphics Debugging. It's quite common, however, for Win32 desktop applications to use 'ripple' launchers, so the EXE you start isn't actually the Direct3D game EXE.
Applications are also free to request that Visual Studio not support capturing them via an API, which is possible here as well. This is done via the D3DPerf_SetOptions(1) method, use of the D3D11_CREATE_DEVICE_PREVENT_ALTERING_LAYER_SETTINGS_FROM_REGISTRY flag, or by reacting to the value returned from IsAnnotationEnabled:GetStatus or ID3D11DeviceContext2::IsAnnotationEnabled.
I want to know if this can be done in the latest version of VS by a simple setting somewhere that causes VS to behave in a way that is equivalent to "ContextMenu">run "a_Java_src_file_with_main" in the Eclipse IDE. I'm using the trial version of VS 2010 Pro on a new W7 platform. Even the minimal helloworld cpp source file added to a project generated from the "empty" template redirects into a command window.
Same question 3 years ago:
Capturing cout in Visual Studio 2005 output window?
And 9 months ago:
How to redirect stdout to output window from visual studio
I'm aware of using OutputDebugString(...) and of redirecting the stream to a file as alternatives.
Capture console output for debugging in VS?
Simple way to do this is to "suppress the console window" by building an executable with a WinMain entry point on windows instead of main.
This can usually be done by editing the project settings, but if you use cmake, like me, these settings are overwritten every time you call the cmake build. So, in this case you need to add WIN32 to executable target in CMakeList.txt or set CMAKE_WIN32_EXECUTABLE to true for cmake configure command.