So there I am, working on a Silverlight app, and between one build & run and the next, my debug output goes away. Where before I had dozens of lines of Debug.Writeline text, I now have only the module load and thread messages.
Yes, I'm in debug mode (vs. release mode).
Yes, my Output window says "Show output from: Debug".
Yes, when I right-click on the output window, every option is checked.
No, my Tools > options > debugging > general > "Redirect all output text to the immediate window" is not checked.
All I can figure (and it's a wild guess) is that for some reason, the VS debugger isn't attaching to the Silverlight app like it should.
What's weird is this has been happening for the last couple of days, out of the blue. And just as suddenly, all my debug messages start showing up again.
This is VERY frustrating.
EDIT: Of course, after returning to the project after the weekend, all Debug messages are back. No idea what was causing the issue, so I'm sure it will happen again.
Now the question is: should I leave this question open in case the problem arises again in the near future? What happens to an unawarded bounty?
I found the same problem and just by setting options → debugging → output window → Thread Exit Messages to true the output windows was begin to send the right messages !?
I had exactly the same issue. Out of the blue, debug.print stopped working. In my case, it used to go to the Immediate Window. Nothing there. Nothing in the Output window. I followed several suggestions to no avail until I found this one at http://www.experts-exchange.com/questions/26894732/Debug-Print-and-Debug-Write-no-longer-work-in-Visual-Studio-2010.html
There is a context menu in the Output/Debug pane. The "Program Output"
menu item was accidentally cleared.
Checked the item and it started working again (even though my output was the immediate window). What a relief...
Ensure that the DEBUG conditional compilation symbol is defined. The Debug class suggests that you "add the /d:DEBUG option to the compiler command line when you compile your code using a command line, or add #define DEBUG to the top of your file".
Did you create or modify an Application config? If yes: the initial created configuration by VS does contains the necessary wiring configurations to enable the debugging at all. Not sure what and if there are counterparts in Silverlight, but in WPF environments simply replacing the app.config will have the same effect as you expierience.
Check the Immediate Window. Check the options. There is a general setting that says "send Debug output to Immediate Window"
Related
How can I ensure reliable use of Debug.Print ?
I know there have been many solutions posted for this, but none of them work. This command just keeps on being broken, sometimes it may work for a while, but generally -- it fails (see the number of SO questions regarding this). The solutions seem to vary, and yet it keeps happening - so here it is again where none of the solutions below are fixing the problem (save for installing on a fresh computer which only works for around 10 projects then fails again)
What I have tried
1. Creating a new application from scratch
2. Using the alternative to Debug.Print
System.Diagnostics.Debug.Listeners[0].WriteLine
3 Checking my app.config which shows
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.2" />
</startup>
</configuration>
4. Checking my settings to see if DEBUG and TRACE are enabled (they are)
5. Checking that the Immediate window is on the correct tab with [Debug] selected in the drop-down (it is)
6. Ensure that I start the application in Debug mode (it is)
7. Removing all extensions / plugins.
8. Installing on a fresh computer. (works for a short period, then fails indefinitely again)
I have no AntiVirus or "potentially" conflicting software on my boxes where I test if this issue is consistent in bare windows, or if there may be another application causing it.
Are there certain cases (in the code itself like async/await etc) which consistently cause no output for Debug.Print ?
I finally found the problem. The Output window doesn't contain this output even when Debug is selected, and my Immediate window disappeared.
How to get the Immediate window back
Click the menu on the top Debug -> Windows -> Immediate or press [CTRL]+[G]
The result showing it works
Caveat: Just because you have the immediate window shown while coding, doesn't mean it will be there when you enter Start Debugging [F5] mode, or vice-versa. It may also disappear and not be there when you restart Visual Studio or start a new application. Just follow the directions above to make it reappear, and mind the other note below.
Note : After doing this, the window appeared as a floating window which I had to dock again. After docking, I tried to clear it using right-click and instead of a context menu, Visual Studio committed suicide, and then restarted - back to the project list screen (it didn't reload my project).
This didn't work for me, what finally got it working again was Project Properties> Build Check Define DEBUG Constant
One easily overlooked possibility is that the project hasn't configured any trace listeners.
Either configure one in the config file or add:
Debug.Listeners.Add(New DefaultTraceListener)
in your code.
This will cause debug output to be written to either the output window or the immediate window depending on your Debugging settings ("Redirect all output text to the immediate window").
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
I am using Code::Blocks 12.11 on Windows 7.
I am writing small programs for learning and they don't appear to contain any infinite loops but regardless, Build->Abort does not work in those situations in which I find that I have to use it for some reason after Build->Run.
In this most recent case, the following is displayed in the "Build log" tab of the "Logs & others" window at the bottom of the screen.
Checking for existence: C:\CodeBlocks\Test_Cpp11\bin\Debug\Test_Cpp11.exe Executing:
"C:\Program Files (x86)\CodeBlocks/cb_console_runner.exe"
"C:\CodeBlocks\Test_Cpp11\bin\Debug\Test_Cpp11.exe" (in
C:\CodeBlocks\Test_Cpp11.)
I exited Code::Blocks, came back in, reopened the project, and immediately ran the program and it ran fine.
EDIT: I found out the problem. If the "console window" - that came up to display cout statements - is still open, then you will have a greyed out Build->Run and Build->Build items until you close that window. My assumption that I needed to do Build->Abort at that point was incorrect. As pointed out in the answer below, that would not abort a running project process anyway, only a build/compile process that may be running.
THis happens when the previous execution is not terminated properly.
On windows, Open up the task manager and kill the commandline processes which contain the output of the previous run. Doing so will restore the build / run to icons to green and they are rendered available.
To kill the running process while you are debugging, click on the red-color 'X' button on the debug bar. This is the button named "Stop Debugging" in the image shown below.
In Code::Blocks, the Build->Abort menu item will abort building (making or compiling) your project. It has nothing to do with killing a running process. Hope this helps you.
When the application has completed and returned from its main function, it will prompt you to "Press any key to continue".
Once you do so, this will abort the launched process and the build buttons will no longer be greyed out.
When running a console application in Visual Studio via "Start without Debugging" (Ctrl+F5), the console remains open at the end of the run asking to
Press any key to continue . . .
thus requiring to activate the window and hit a key. Sometimes this is not appropriate.
Why this matters:
At the very moment I write json serialisation code, my workflow goes like this:
adapt c# code
run a console app that writes file out.json
view out.json in the browser with a json viewer
do this again and again, no need to debug anything, just trimming serialisation and check output is good.
It is workflows like this, where the "press any ..." behavior is hindering as it requires the steps
activate the console window
press key
.
No answers:
Starting the application outside VS in a separate console is not an answer.
Saying, you dont need this.
I'm pretty sure that you cannot affect or change this behavior.
As you mention, it has nothing to do with your application itself, because it doesn't do it when you double-click on the EXE. You only see this effect when you run the app from within Visual Studio without the debugger attached.
Presumably, when you invoke Ctrl+F5, Visual Studio is running your app in a particular way that causes the console window to remain open. I can think of two ways it might be doing it:
%COMSPEC% /k "C:\Path\To\YourApplication.exe"
or
%COMSPEC% /c ""C:\Path\To\YourApplication.exe" & pause"
With either of these, the pausing behavior you're seeing is baked right into the command used to launch your app and is therefore external to your application. So unless you have access to the Visual Studio sources, you're not going to change it. Calling an exit function from your app won't have any effect because your app has already quit by the time that message appears.
Of course, I can't see why it really matters, aside from an issue of curiosity. This doesn't happen when you start the app with the debugger attached, which is what you'll be doing 99% of the time when you launch the app from the IDE. And since you don't ship Visual Studio along with your app, your users are going to be starting the app outside of VS.
In response to the updates made to your question, the best solution would be to change your app so that it is not a console application. This behavior doesn't affect standard Windows applications; when they get closed, they close for good.
If you do not require any output on the console window, then this is very simple to do: just change the "Application type" in your project's properties. A Windows Forms application will work just fine. If you do not display a window (aka form), one will not be automatically created. This is the difference between regular Windows applications and console applications, which always create a console window, whether you need one or not.
If you do need to display output on the console window, you have a couple of options:
Create and use a simple form with a ListBox or ListView control. Each line that you would normally output to the console, you add as a new item to the list control. This works well if you're not using any "advanced" features of the console.
P/Invoke and call the AllocConsole function to create a console that your Windows application can use. You do not need a form for this.
I found a solution that works if you are using python (I could not test anything else).
You need to go to
Tools -> Options -> Python Tools -> Debugging
Uncheck Wait for input when process exits normally.
I hope you can apply this somehow to your problem.
2020 UPDATE : Microsoft has listened.
It also closes the console in "Start Without Debugging" mode ;)
The setting is a little buried, but works :
Well, at least in Visual Studio 2010, typing
Console.ReadKey(true);
Removes the "Press any key to continue....."
According to the VS2019 documentation:
Automatically close the console when debugging stops: Tells Visual Studio to close the console at the end of a debugging session.
It works, but only if you make sure your project starts with the debugger on. This sounds trivial, but I was trying at first with a solution with two projects, one Console one to copy files to use in my app, the other to run the actual app. I set the Console one to Start without debugging because I don't need debugging on it, but that did not close it after it ran. Only when setting it to Start (with debugging) this option worked.
In vs2017 you have to uncheck the python environment setting under the vs-options:
in german: Auf Eingabe warten, wenn der Prozess normal beendet wird
I'm using Visual Studio 2008. The Trace output is no longer being shown in the Immediate Window any of my forms except the primary form. When it executes code from within another form (called from that primary form) the Trace output doesn't show up. It used to be fine, and one day it just stopped working. I think this is a setting in VS2008. Anyone have any idea what setting this would be under?
It's got a TraceListener in the code, and that hasn't been touched.
Can you do a quick check and see if the second project is compiling in Release or Debug? If it's Release there's a chance Trace won't be defined and Trace output hence won't show up.
Check that you're referencing System.Diagnostics.Trace, and not the Page.Trace TraceContext object. If you're just doing Trace.Write it might be resolving to the wrong place, depending on your using directives.
There's an item under Options - Debugging - General: "Redirect all Output Window text to the Immediate Window". That should do the trick.
Patrick