Break point hangs DirectX-based program in full screen mode - c++

I started making a game, I have a global class that reads in a csv file, loads two direct x surfaces, and creates the background.
the surfaces are a tile sheet and the other the background created from the tiles. the background surface does no work, after instillation I check it and if null a message box appears. It always shows the message box.
I tried setting break points to see if the values are read in corectly fron the csv file but the program will not run. a box appears in the task bar, the program goes full screen but the screen goes black and does not show the message box and can only be stopped by ctrl,alt,del.
No matter were I put the break point even if it is in a different source file this happens. does anyone know why ?
p.s it is not a multi thread application.
Edit:
I am using visual studio 2005 and direct x 9.c

With directshow, it can be bothering to debug in full screen : if you really have to do it, I suggest either using a second screen (this way, you can debug on your screen 1 while your program runs in full screen on your screen2).
If this doesn't work, you'll have to use remote debugging (i.e. run the programm on a computer and debug on another).
Most probably, what happens is that your debug point is triggerred, but your screen is held by directshow and thus visual can't be displayed. Thus your programm is actually blocked by visual, it doesn't answer to anything (as the event loop is blocked by the debugger)
In order, I would:
run in windowed mode
run in dual screen with your debugger on other screen
try to setup remote debug (good luck)
maybe use the old good way to debug with printf / traces (log4cpp e.g.)

In visual studio, if your project is not configured in debug mode (and instead is configured as release) you will not be able to debug, so any breakpoints you set will be ignored. This could possibly be the problem.

forced it in windowed mode , you may modified or hook the application

Related

Visual Studio with OpenCV: Can I keep the image windows open even after program exits?

I have recently started using OpenCV 2.4.10 with VS2013. My program involves displaying a few images using imshow() along with outputting some values in the console window using cout. I have used getchar() before returning from the main function. This allows me to see the program output before the program exits.
Once the program exits, all the windows are closed. Is it possible to keep the windows open even after the program exits?
I found a related post but the answers are for the debugging phase and not after the program exits. As suggested by other answers to that post, my Properties>Configuration Properties> Linker> System>SubSystem is already set to console. Another post suggests using ctrl+F5 instead of F5. That keeps the program output window open but the windows showing images close down.
I looked through the OpenCV documentation on User Interface related functions but couldn't find my answer as well.
I don't think you can. After the program ends, it will close also the windows of your images.
If you need to view the images after program end, you could simply save (using imwrite) the images and see them in your preferred image viewer.
If you need to check pixel values, type of matrix and other useful stuff, you should install Image Watch extension in Visual Studio. Note that also this will close when program ends.

Getting debug output from a crashed VS2010 application

Question: Can I set up VS2010 so it automatically writes debug output to a file?
Motivation: I have a DirectX 9 application that I'm trying to debug. I've noticed that when my application is fullscreen, it may crash under certain conditions. Normally I would just check my logs or DirectX debug output. However, the way my program crashes prevents that. It freezes and does not respond to any my attempts to end it (including "End Process" from task manager). Moreover, it also freezes my VS2010, and so VS doesn't respond to any commands either. The only way out of this whole thing that I've found is to End VS process. This, however, also destroys the output I'd very much like to read.
Now I see two ways out of this. First is to write all the debug info to a file but I have no idea how to do it. Second is to make my application crash in a more friendly way, but this seems like a difficult task.
Probably MiniDumpWriteMiniDump(..) helps on this. You can at any time dump the current state of the process to a file. After that, you can open the dumps with Visual Studio and analyze the state of the process - this includes callstacks of every thread, variable values...
Try to identify conditions in which your process crashes and write one or more dumps.
Another try is to install the Windows Debugging Tools and use WinDbg to debug your application. This is not as comfortable as Visual Studio, but allows a deeper insight.
Edit:
If there are debug statements made with OutputDebugString(..), you can use DebugView (from Microsoft, earlier Sysinternals) to display it.

Is it possible to make a Windows screensaver without Scrnsave.lib?

I coded a Windows screensaver using C++/WinAPIs some time ago but now when I try it on Windows 8 at a logon screen (when no users are yet logged in) it doesn't seem to work. It is clearly a bug in Windows 8, because when I reboot the system my screensaver begins to work just fine. (Note that this behavior never happened on any previous version of Windows.)
What happens is that when the screensaver starts, the screen turns black and nothing happens after that moment. Obviously I can't debug it with the Visual Studio, so I added a trace statement into the first line where it should begin executing in WM_CREATE in ScreenSaverProc() but that line never gets called when the screensaver hangs up like I described above.
This tells me that some initialization code hangs up before the WM_CREATE message is sent, but to fix that I do not have access to that code because Microsoft's tutorial on WinAPI screensavers instructs to link to Scrnsave.lib (or ScrnsavW.lib in my case.)
So I was wondering, is there any way to build a WinAPI screensaver without using Scrnsave.lib?

Ogre3d restoreConfig causes app to hang on Ubuntu

Building an app for Ubuntu using Ogre3D, CEGUI, OIS which is now all compiling and running as expected. Having got the basic app running I decided to now build a custom config file which I can store both graphics settings (ie. resolution, fullscreen, etc) as well as other configurable settings I will need in the app down the track.
As a starting point I changed from calling mRoot->showConfigDialog() at each startup to :
if(!mRoot->restoreConfig())
mRoot->showConfigDialog();
this was meant to restore the config from the 'ogre.cfg' file which exists and so it did, but got to loading a skybox texture on the first scene create and just sat there doing nothing.
Since that wasn't what I wanted anyway I tried setting things up manually like :
RenderSystem *rs = mRoot->getRenderSystemByName("OpenGL Rendering Subsystem");
mRoot->setRenderSystem(rs);
rs->setConfigOption("Full Screen","No");
rs->setConfigOption("Video Mode","1024 x 768");
Those matched the settings from 'ogre.cfg' that I was using prior from the showConfigDialog() function. I got the same issue with this manual configuration however, while loading the skybox textures it just stops.
I can't work out why these changes have any bearing at all on how the app runs and since OIS grabs the input and locks the mouse to the screen I am having trouble trying to debug it with gdb.
Regarding the mouse locking, you can run gdb on another display. It can either be a display on the same computer (including options like Xephyr that create virtual displays nested in the current display, or just a second session on a different display - if you have a working .xinitrc running two or three X sessions at a time is simple), or it can be on another machine on your network (ie. via ssh -X).

XCode automatically deactivating breakpoints

I'm using xcode in C++. I'm trying to debug my project, but at random intervals, it seems to ignore my breakpoints. There are three things that it does:
1) Sometimes, when I run, it automatically switches to "de-activate break points" mode. (the relevant button goes light and says "Activate")
2) Sometimes when I run, ALL of my breakpoints go "can't find" mode, with the yellow insides. I need to click twice on them to get them back dark blue (once to light blue = inactive, once to dark blue = active)
3) Sometimes, when I run, my breakpoint is dark blue, the button says "deactivate" and it still just ignores my breakpoint, running straight past it.
This makes it very difficult to debug my program...
I should add that I'm using XCode 3.1 beta on OSX 10.5.6, in case that matters.
thanks.
Try unchecking the Load symbols lazy in the Debugging panel in Preferences
alt text http://img.skitch.com/20090209-gj947qk7dxdyms1wij4q5em2f2.jpg
Had the same problem but only restarting the iPhone Simulator seemed to fix it.
I faced the same issue right now.
I tried all the options : enabling the GCC, active, base targets and restarting and closing xcode, nothing solved.
I finally restarted the simulator and things have started working.
I have more or less the same set of issues, and this suggestion of loading symbols lazily unfortunately does not resolve it for me. Moreover, I am not developing for the iphone, just a regular application.
To be specific, sometimes I can't disable or enable breakpoints on the fly - sometimes my code doesn't stop in breakpoints which I later prove are being executed (with print statements) and nothing I can do will make it stop there - I see that very annoying debug symbol with an orange center, even though I only have one project active.
Quitting and restarting XCode occasionally has an effect - and annoyingly, there have been a very small number of cases where quitting and restarting or rebuilding from clean fixed hard-to-diagnose compilation/linking errors. Unfortunately, I just tried all of these with no effect.
(Unrelated, my keyboard shortcuts are also unreliable. My shortcut of F2 for continue worked for weeks for me, stopped working for a long time, was working this morning and now doesn't work at exactly the same breakpoint it worked before - yet my F1, step over, key has been completely reliable...)
I'm a little disappointed to have to do so much debugging with print statements!