Who buggered my debugger ?

[Mike Pliam]

Sorry to repost, but there were no responses to my first post and I am growing desparate.

See: http://www.codeguru.com/forum/showthread.php?t=474843

Visual Studio 2005 C++ (WinXPPro) works just fine with the single exception that I am unable to write to the Output window using TRACE macros, _RPT macros, or the Win API OutputDebugString(LPCTSTR ..).

http://msdn.microsoft.com/en-us/library/aa363362.aspx
http://msdn.microsoft.com/en-us/libr...45(VS.85).aspx

Using the Win API function BOOL IsDebuggerPresent() indicates the a debugger is present when the compiler is run in the Debug mode, yet no debug information is sent to the output window, only the usual stuff that is sent in Release mode.

This problem occured suddenly about 2 weeks ago. I cannot associate it with anything else that I might have done.

Any thoughts or ideas greatly appreciated. (There is no 'desperate' icon or I would post it here!)

[Paul McKenzie]

1) Get DebugView from sysinternals.com.

2) Run your program without the debugger, and see if the messages show up in the DebugView window (especially when using OutputDebutString). If not, then there is something wrong that has nothing to do with the "Output Window" of VC++.

Regards,

Paul McKenzie

[VladimirF]

Did you install any add-ins recently?
Could you check the "Show Output From" combobox - is there anything besides Debug and Build? BTW, is Debug selected?

[Mike Pliam]

Paul
Did as you suggested. Running without debug (still in Debug configuration) results in all the appropriate debug output appear in the DebugView window. What conclusions can be drawn from this observation?

Vladimir
While I cannot pinpoint the onset of the debugger problem, in checking my downloads, I find none that I can reasonably associate with the the problem. Of course, Microsoft is continually updating the system, and it is difficult to know exactly what changes might have occurred.

Thank you both for your kind input.

[Paul McKenzie]

Paul
Did as you suggested. Running without debug (still in Debug configuration) results in all the appropriate debug output appear in the DebugView window. What conclusions can be drawn from this observation?

Then there is something fishy going on with the VC++ setup for that project somewhere. Since you see the output messages in DebugView, nothing is wrong with the build of your program itself

I would try a create a new project and see if the problem still exists.

Regards,

Paul McKenzie

[VladimirF]

What about my other questions?
Could you check the "Show Output From" combobox - is there anything besides Debug and Build? BTW, is Debug selected?

[Mike Pliam]

Vladimir
Only Debug and Build are present in the combobox, and selecting either one or the other does not solve the problem.

Paul
Completely rebuilding a new project results in exactly the same problem. Further, compiling and running previously built programs gives the same result, that is, no debug output to the Output Window.

Something has obviously been altered in the VS application, but I cannot figure out what.

[VladimirF]

Check out Tools -> Options -> Debugging -> General:
Redirect all Output window text to the Immediate window
Sends all debugger messages that would normally go to the Output window to the Immediate window instead.

[Mike Pliam]

Vladimir
Thanks for the suggestion. Still no debug output to the Immediate Window.

[Mike Pliam]

This problem has never been resolved. It has now reared it's ugly head again in my VC 2005 Vista compiler. I beleive that this problem is widespread. When attempting to run in Debug mode, it is accompanied by the output:

Binary was not built with debug information.

There are a number of threads I Googled using this phrase. One of them mirrors my problem precisely, including all of my attempts to fix the problem, none of which have been successful.

See http://social.msdn.microsoft.com/For...4-34d086fe57f5

As noted in the above cited thread, all of the settings are as perscribed by the Microsoft technical person, none of them were ever changed, and a Program Debug Database (PDB) file is being generated.

I obtained DebugView from sysinternals.com and, while it works just fine, it's not quite as convenient as the compiler's own debugger.

I had hoped that you gurus would put your heads together to resolve this problem. I have exhausted my own resources without success.

[Paul McKenzie]

I had hoped that you gurus would put your heads together to resolve this problem.

We can't fix a problem that we can't duplicate. We don't have your project, or even if you're doing everything correctly.

First, are you sure you are running the correct version of the program you believe you're running? For this, you need to get a program like ProcessExplorer (again from sysinternals.com) to verify that the executable being debugged is the one you just built. Many times, if you have executables or DLL's that are located in multiple places on your system, the wrong versions of these programs are running.

Second, build a release version. Compare the size of the release version of the program with the size of the debug version. If the release version and the debug version are roughly the same size, then there is something wrong, since debug versions are usually much bigger, sometimes by several magnitudes, than a release version.

Third, build a release version with debug info. If you can debug that, then there is something wrong with your build settings for debug builds.

Regards,

Paul McKenzie

[Arjay]

Create a simple Win32 C++ console app project. Write in a few lines of code, set a break point. Debug. Is the break point hit?

If no...

Uninstall Visual Studio. Search the registry and remove any user specific data that the uninstall might have left. Remove any references to Visual Studio.

Reinstall Visual Studio.

If yes...

You have a problem in the project settings. Create a new project type similar to your project and compare the debug related settings.

Another option is to go to a different machine with Visual Studio and run your project.

Btw, you made a comment with regard to 'the system always changing' because of Microsoft installing updates. Understand that most of us receive the updates all the time autoupdate on several computers) and we don't seem to have issues like this. I'm running Visual Studio 2003, 2005, and 2008, building projects in C++ and C#. I receive autoupdates and all three versions work fine - this is on multiple computers as well.

It might be better to think "What have I done?" rather than "What has Microsoft done to me?".

[Mike Pliam]

Paul - the size of the debug version executable is almost twice the size of the release version. Attempting to debug the release version results in the same output as when I attempt to debug the debug version. I have eliminated all other copies of the project from the machine.

Arjay - I have done as you suggested and when running the Win32 console app in debug mode, the breakpoints are hit with no problem. However, the _RPT(0, "...") statements no longer show up on the output, nor is an intentional memory leak detected by adding the statement to main as the used to before I encountered this problem.

	int iOrg = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);	
	_CrtSetDbgFlag(iOrg | _CRTDBG_LEAK_CHECK_DF);

As I have mentioned, I have encountered this problem on two different machines running 2 different OS s (Win2k and Vista).

It would appear that there is some problem with the project settings. I have tried to compare the settings and cannot find the problem, but I admit I may have missed some item.

As far as blaming Microsoft, I believe that if you look at the thread I posted above you will see that I am not the only one who has encountered this problem. I always monitor the updates that I receive from Microsoft on all of my machines. To a great extent, they are security fixes and I am greatful for them. But they are all 'black boxes' as far as I'm concerned. And while I pretty much know what I have done on my machines, I am not certain what side effects some of these updates might have, much less any of the other viruses and bugs that I might have picked up from the Internet. In any case, persuing this aspect of the discussion is fruitless. Remember, even paranoid people have enemies.

[dc_2000]

Completely rebuilding a new project results in exactly the same problem.

Well, Mike, why don't you start a small console project (make sure that it still doesn't output any debug messages on your end) and attach it here and we'll see if it repeats on our end.

most of us receive the updates all the time autoupdate...

My suggestion to all of you who have your Windows updates set to Automatic to change it to "Download updates for me, but let me choose when to install them." The reason being, you will be able to select "Custom install" (instead of Express one) and see/select which updates are being installed on the system. It will also prevent unexpected rebooting of your system at night that is done when those updates are download and installed out of the blue.

Mike, from what you described and from what other people have experienced on that MSDN forum thread you posted, it looks like the issue is not specific to your copy of MSVS, besides being quite old as well (going back to 2005). Since you say that the same problem manifested itself on Win2k and Vista, it might be that you have an older build of the VS. Did you check for any Service Packs for it? That might solve it.

[Arjay]

My suggestion to all of you who have your Windows updates set to Automatic to change it to "Download updates for me, but let me choose when to install them." The reason being, you will be able to select "Custom install" (instead of Express one) and see/select which updates are being installed on the system. It will also prevent unexpected rebooting of your system at night that is done when those updates are download and installed out of the blue.

That's fine, in terms of scheduling of the updates - schedule them when it bests suits you. The important thing is to get them installed.

I agree with regard to installing the Visual Studio SP's. There have been several SP releases for 2005 and if you don't have them installed, then I would install them first.

Actually, I would uninstall, clean the registry, reinstall, and then apply ALL the service packs.

When you look at it, the updates go out to thousands of folks without issue - there's only a relatively few folks that have issues (and we don't know that this is related to updates).

I'd also install VS on a clean machine and then create a new console project. If that works, I'd try the real project.