I wrote a desktop app in Visual Studio 2013 Community, the one that just came out and I am trying to use the graphics debugger. The problem I am having is that when I start up the debugger the program, the program never gets to the first frame, it only shows a white screen. Also, there is no output to the debugging interfaces. The program runs fine and the DirectX10 Graphics work fine when I do not use the graphics debugger. I have tried setting the compiler to mixed and that didn't seem to change anything. I also searched around for locale issues as I found that could be a possible issue but it didn't seem to make a difference either. Any ideas on what I need to change or setup or fix?
EDIT
It worked correctly one time but I am having trouble getting it to work again. The message in the diagnostics hub is: Profiling of 'Graphics Frame Capture' started.
I'm not sure but looks like VS 2013 Community doesn't support graphics debugging, assuming this article is up to date: https://msdn.microsoft.com/en-us/library/hh873207.aspx
Related
I am making app to increase productivity in our company. It reads the whole .csv file and puts its contents to a table in .pdf format. I am using QT as GUI library and PoDoFo as .pdf library.
The thing is, after I let user select .csv file to get data from and path to save generated .pdf, the program crashes in two minutes or so. It varies from case to case. I was able to "track" the issue down to the QFileDialog.
It doesn't matter if I created it on the stack, or dynamically still the same thing happens. From the moment you press "Choose" in the GUI, which opens up file dialog, program will crash in something around a two minutes giving this in Visual Studio Community 2017
I was able to create minimalistic code, to reproduce the error. I am using Windows 7 Pro, Microsoft Visual Studio Community 2017, compiling 32-bit debug
.h,.cpp,.ui files: https://www.dropbox.com/sh/cf057p4lnumesol/AAD39zDJnrxGChXAuE7y27Kra?dl=0
Any help would be appreciated, I've spent 5 days of my free time trying to figure this out. Thanks
EDIT: I understand that the "Frame not in module" means that visual studio doesn't have debugging symbols for the part of code where crash occurred, since I did not built qt myself, that makes sense.
EDIT2: I am using QT Visual Studio Tools addon version 2.3.2
Qt version is 5.12.2
EDIT3: Crashes only occurs when compiling for 32-bit arch.
EDIT4: Crash is happening only if using native file dialog. If option QFileDialog::DontUseNativeDialog is set, then no crash occurrs.
Not sure if this is related, but I had an issue where if I gave a path to the FileDialog it would grind away for a few seconds because it was somehow interpreting it as a network path. To fix this I gave it a path that had a prefix of "file://". To accomplish this I did this:
QUrl().fromLocalFile(cell_info->progDir()).toString()
The original path came from cell_info->progDir(). Somehow that path was a regular windows specific path. Once I wrapped it in the from LocalFile call it produced what I needed for all platforms I was using it with.
Again, I have no idea if this is related to your issue, but it sounds fishy like it is grinding away in the background on something. If this is not related feel free to ignore.
I have been improving an OpenGL code of my own since some days, and now I got a terrible surprise: My code works properly if run from inside CodeBlocks IDE (by Menu-> Build -> Run), but if I open it from the Windows Explorer, the program will still open and issue messages on the console as if it would be running properly, but I just get a blank screen.
I have trying re-building the code to see if the problem disappears from Windows, or to see if it also affects the run from inside CodeBlocks, but the outcome is still the same.
Some days ago (before much of the code change), I could start the program from both Windows and CodeBlocks and run perfectly in both cases, so this is totally surprising for me now.
I use GLFW3 and GLEW and I am linking to the following libraries:
C:\msys64\mingw64\lib\libglew32.dll.a
C:\msys64\mingw64\lib\libglfw3.a
opengl32
C:\msys64\mingw64\lib\libsfml-system.dll.a (I use the clock of this library)
gdi32
On the meantime I have deinstalled and installed msys64, but this didnt affect my other OpenGL projects linking the same libraries, so I suppose this is not the source of the problem
How would I proceed to debug such an issue? I have no clue about how to start troubleshooting this, so any comment on what extra info I should post is welcome.
Update: If I open the application from the GPU PerfStudio and CodeXL, everything works just fine, but not when I open via Windows Explorer.
How would I proceed to debug such an issue?
When I deal with bugs like this I use a tool called CodeXL. You can download the latest version here. It automatically breaks on any OpenGL error and shows you which of your OpenGL function calls caused it.
It is free and it works also with non-AMD GPUs.
It should not take you long time to learn how to use it: you just create a new project, give it path to your project folder and .exe and hit run. (make sure that Debug->Breakpoints->Break on OpenGL error is checked)
//Moreover, it visualizes your buffers, shows you your loaded textures, etc.. Definitely check it if you plan to program more Windows+OpenGL in the future.
I've been searching arround StackOverflow but seems I can't find the exact explanation for my problem:
I am running a GUI Application compiled under Visual Studio 2012. As it is a GUI application, sometimes it's quite hard to Debug it normally, so I need to printout some values while executing. I've done a couple of printf but the problem is that, as it is a GUI application there is no Console available while debugging it. I need to debug and have a Console to display these output values from printf. I know under CodeBlocks it is possible to do so, however the project is quite big to have to migrate everything to gcc CodeBlocks.
Could anyone tell me how to display such console or how to workaround the problem and have a similar result?
Thank you very much
Windows applicaton can't be both GUI and console.
There is a workaround however:
If you applicatop is based on MFC use TRACE macro.
Otherwise make your own wrapper around OutputDebugString function.
Both will output to Visual Studio's 'Output' pane when you launch our program under debugger
An of course you can always output diagnostic messages to good old log file.
I'm running into a strange thing while making a game in VC++. I'm using the Cocos2d-x platform and VC++ 2010 in Windows 7 and it works perfectly fine on my machine. However, I have another computer that is Windows XP. I am currently using /MT so there is no problem with the runtime library, but the program doesn't run in Windows XP and it doesn't even produce an error. I have tried with 2010 C++ redist on the other computer, and it doesn't work with or without. There is nothing in the console and no error log. Nothing appears odd in DependencyWalker, only missing internet explorer frame stuff. What can cause a program on windows XP to execute and close immediately without leaving an error?
Anyone has any ideas? I am using the game framework's dynamic linked libraries, so could that be a problem? Also, even though I linked statically, my executable is only about 140 KB. Is something messing up?
Thanks for any help.
EDIT: There's also an interesting problem with CRT I ran into before. When I ran the program with permission level "asInvoker" on windows 7, I got a "CRT Not Initialized" error. Once I set it to "highestAllowed", it started working but I was wondering if it had anything to do with CRT?
Okay, I've found the problem. It turns out that my other computer has an integrated Intel Graphics card that doesn't support the graphics renderer (OpenGL ES 2.0) that the framework uses. That's why it ends up crashing without outputting any errors.
Thanks to anyone who helped.
At my shop, the main product app is a mongrel built on MFC, QT and other random things devs have thrown in over the years.
In the current stack, Qt toolkit is on the way out, but still features heavily.
If I have SQL 2005 Management studio open and have to do a full build, it usually hangs a CPU (even after the offending process is taken out back and shot...) during the qt specific parts of the build (Moc'ing and UIC'ing)
has anyone seen anything like this? any ideas what the problem could be?
In my experience, some of these tools are capable of looping forever (qt4: lupdate/lrelease for sure).