Does anyone know… If there are Debug.Print() commands, but the debug output is disconnected, how does NETMF behave exactly? I’m now fighting some nasty bugs, when program is not working correctly when the USB cable is attached (no debugger connected), and works fine if the USB cable is disconnected…
That sounds more like a timing issue. Things run slower under the debugger. Check for potential race conditions.
In this case, it’s actually opposite. I have a blinking led on a separate thread of lowest priority, and it indicates slower operation when there’s no debugger attached. It feels like the program wants to print debug information, but since it can’t, it struggles with it and still tries. That really drives me crazy right now…
1 Like
Have you tried to #ifdef all Debug.Print with DEBUG and then build Release build. Do you still have the same issue?
Yes, that’s what I do now. My Debug.Prints are all suppressed, but internal ones are not. For example, if a thread is aborted, it raises a non-breaking exection and outputs plenty of text. This is exactly where I’m having issues.
Interesting, I don’t recall having such problems with previous SDK…
Here is your answer…
try using the following code:
if (System.Diagnostics.Debugger.IsAttached)
{
Debug.Print("I'm attached to a debugger");
}
else
{
//No Debugger is attached blink LED...
Mainboard.SetDebugLED(true);
}
Wrap all your debug.print as the above or create a procedure with the above code and call it.
Hope this helps 
Cheers,
@ Jay Jay - His problem (at least that what he thinks) is the Debug.Print statements that are out of his control.
This is quite interesting. Earlier this week a work colleague conplained about a similiar thing. He said that if he runs his code in debug mode mode its much faser than when he run it out of debug mode. More specifically his SD card reads appeared to slow down when he did not run in debug mode. He also had debug statements in.the.code that he thought slowed down. If you keep the USB connected and run as debug and then as normal run mode, do you also see a difference in run speed? That was what happened in his case.
@ Simon from Vilnius - I noticed the same thing when moving from 4.1 to 4.2.
https://www.ghielectronics.com/community/forum/topic?id=9461
Unfortunately I never really investigated it further, I would be interested in the outcome of this.
I was unable to reproduce your (old) problem. I guess that one is fixed.
Regarding my code, I couln’t pinpoint the problem, so I rewrote that part of the program from scratch so it is less likely to throw an internal exception with printing to debug output. Works much better now, but it of course could be due to better programming logic, not debug printing.
Hi, I’m experiencing the same problem and got pointed here by @ Architect from this thread
https://www.ghielectronics.com/community/forum/topic?id=17241&page=1#msg171495
Is this problem resolved?
No, not yet (if ever). Just keep the cable disconnected when not reading debug output.
Is it raised with the NETMF team?
Could this be a temporary workaround ?
if (Debugger.IsAttached)
{
Debug.Print("Test");
}
@ Simon, you meant connecting the power source using the DC Jack power source instead of USB can solve this problem?
Would be great if yes.
I know I can turn of GC debug prints.
But is this also possible for exceptions and other stuff like “The thread ### as ended …”?
What do you mean ? :think:
To me, this little code snippet does the trick. It’s only a workaround, indeed, and it should be placed before any Debug.Print(), which is not really user-friendly, I admit.
But it still has some advantages : as soon as you stop debugging, “Debugger.IsAttached” becomes false, so your device will not execute Debug.Print() statements anymore. If you then re-attach the debugger, via Debug-Attach to process, then Debugger.IsAttached becomes true and your program will display Debug.Print() statements again.
It could be seen as a live “#define DEBUG” statement 
While we are at it: What if my system has been running for a few weeks, without a cable attached, and I want to see how it is going, can I attach a cable and then do something in VS to see the messages?