Who buggered my debugger ?

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!)

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

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?

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.

Quote:

---

Originally Posted by 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?

---

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

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

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.

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.

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

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:

Quote:

---

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. :(

Quote:

---

Originally Posted by Mike Pliam

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

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?".

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.

Code:

---

        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. :)

Quote:

---

Originally Posted by Mike Pliam

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.

Quote:

---

Originally Posted by Arjay

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.

Quote:

---

Originally Posted by dc_2000

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.

I also had the same problem with debugging and OutputDebugString() starting from 2-3 weeks ago when MS updated my Visual Studio 2005 with KB971090 which is a 250MB update for 3 ATL vulnerabilities. The link below has more information and has a long list of files patched.

KB971090

I disabled my Windows' auto-update and uninstalled the KB971090 update(under the Visual Studio's Add/Remove program) which took about 30 minutes. Fortunately, I do not use MFC and ATL in my work, so I do not need this update. Although it is security update for ATL, MFC shares some components with ATL, so even the MFC and CRT(not sure why) is affected/updated. More information for the ATL vulnerabilities patched, is in the link below to see if it affects your applications.

ATL vulnerability developer deep dive

Inside the Active Template Library (ATL) Security Update Video