Now I really do quite like the new Application Insights with Visual Studio 2013, and I don't want to remove it. However, it does spam my Debug output quite a lot.
I get rows upon rows of output like
Application Insights Telemetry: {"ver":1,"name":"Microsoft.ApplicationInsights.PerformanceCounter","time":"2015-04-23T11:38:03.1252550+01:00","iKey":"758c18d5-055e-48a8-bbcf-9c3301402b2c","tags":{"ai.internal.sdkVersion":"0.13.2.132","ai.application.ver":"Unknown","ai.device.type":"PC","ai.device.id":"Pat-PC","ai.device.oemName":"Dell Inc.","ai.device.model":"Dell XPS430 ","ai.device.network":"6","ai.device.language":"en-GB","ai.device.machineName":"Pat-PC","ai.device.os":"Windows NT 6.1.7601.65536"},"data":{"type":"Microsoft.ApplicationInsights.PerformanceCounterData","item":{"categoryName":"Processor","counterName":"% Processor Time","instanceName":"_Total","value":35.9710731506348,"ver":1}}}
This kinda makes it impossible for me to actually use the Debug output for my debug statements. How can I silence Application Insights, or configure Visual Studio to just not show those statements?
To simply turn off these messages, with no other side effects:
TelemetryDebugWriter.IsTracingDisabled = true;
Hans Passant is right. DeveloperMode is what triggers AI to write events in DebugOutput. Note though that it also forces AI to send data immediately. So if we set it to false data will be batched and sent out once a minute.
Related
My UWP app goes into UI freeze state sometimes and I don't know why。 I've checked the code about view model and async-await calls. And I've tried to use the performance profile tool in Visual Studio to get timeline but it only shows the time and duration time about the UI freeze. I have run out of ideas now.
I tried the dotTrace but it seems that I cannot use it to profile UWP application. Even I " disable the Compile with .NET Native tool chain option in Visual Studio (via the menu Project | Properties... | Build) and rebuild the project."
https://learn.microsoft.com/en-gb/visualstudio/profiling/profiling-feature-tour?view=vs-2019
There are many reasons for UI freezing, including code endless loops, asynchronous methods are not handled properly, program errors, etc.
Most of them occur in asynchronous method processing and UI rendering.
When calling asynchronous methods, use the async/await keywords, like:
//define
public async Task asyncMethod()
{ }
//use
await asyncMethod();
Reduce resource consumption when rendering a large number of data templates through virtualization.
If you have a large list to render, if virtualization is not enabled (referring to controls with virtualization, such as ListView), or used, but the conditions of virtualization are destroyed (such as adding ScrollViewer outside ListView ), This will also cause the UI to freeze and will not return to normal until the list is rendered.
Please check your code for the above problems, or provide a minimal reproducible demo so that we can analyze where the problem occurs.
Best regards.
I would suggest you try to use the Visual Studio debugger to find out what the code is doing.
First, make sure that you are set "Debug" mode and that the debugger is going to run on "Local Machine" (there are other options here, but I'm trying to keep things simple).
Then, click on the "Local Machine" button to run your app using the debugger.
Once your app freezes, click on Debug-Break All:
After that, I suggest you use the various Debug commands to further debug your application.
For example, you can use the "Call Stack" menu item/window to view what your code is doing. You can also use the "Threads" menu to see what threads are running. If you have suspect areas in your code, you might consider adding System.Diagnostics.Debug.WriteLine() statements to print out informative messages, and then use the "Output" menu item/window to see what is happening.
If your app first freezes, and then crashes after some time, then this could be because your tasks don't have correct exception handling. You might consider adding an UnobservedTaskException handler to your code to help you find this problem.
I'm finding my Output Window's content quite unpleasant to use, as the window is about 90% full of debug lines from IIS Express and from Application Insights. Ideally I would like to filter the Debug sources that write to that window, but maybe I can configure either source to not write so much debug data, e.g. maybe set a higher minimum level like Error vs. what looks like Trace, or at least Info.
What can I do so I can more easily see my own debug statements and important stuff, like WPF binding errors?
I've found an excellent solution for most unwanted info in the Output Window in this answer, but there is still a lot of clutter from ApplicationInsights. Is there no way to configure this locally to only write at level Error?
there's no error level concept for ApplicationInsights output all up (some things like custom events, metrics, etc, don't have the concept of an error level).
if you want to disable the output, you can either set DeveloperMode to false, or use TelemetryDebugWriter.IsTracingDisabled = true; to disable output.
(disabling output will make any of the application insights tools in visual studio while debugging no longer function, though. the AI VS extension is watching the output window for those events to power content in Diagnostics Tools window, debug search, and local CodeLens scenarios)
I need my Visual Studio extension to react to debugging events. I've registered a IDebugEventCallback2 and I'm receiving events, but all I get for each event is an opaque IDebugEvent2 and a Guid, many of which are not only undocumented but don't appear anywhere on the web (or in my registry).
My specific requirement at the moment is to know when the process is Continued - ie. the user has hit Continue, Run to cursor, etc. What Guid should I be looking for?
Or is there some other event family that I should be subscribing to?
(More generally, is there some way I'm missing to find out about the events that are delivered to my IDebugEventCallback2::Event callback, when many of them don't appear in MSDN or anywhere else? Thanks!)
There is no easy way to do this. Actions such as Continue and Run to cursor are abstractions implemented by Visual Studio and do not correspond to any unique event(s) with respect to the debug engine. The debug engine event reporting interface IDebugEventCallback2 will enable you to get notified only on fine-grained events such as when creating a breakpoint or reaching a breakpoint.
While Visual Studio enables you to perform actions such as Continue and Run to cursor programmatically, it does not provide a direct way to get notified when they are taken.
You can use EnvDTE.DebuggerEvents.OnXxx events to get notified when something is about to happen. In particular, the OnEnterBreakMode event enables you to intercept a breakpoint hit and possibly take an action. You can also inspect all the details of the reached breakpoint(s) using the current EnvDTE.Debugger inside the event handler.
Now with some effort, you can use these constructs to implement events that correspond to all Visual Studio debugging actions including Continue and Run to cursor accurately. If you require additional events not provided by EnvDTE.DebuggerEvents (such as when a breakpoint is inserted), you have no choice but use IDebugEventCallback2.Event. In this case if you have specific events in mind, please mention them explicitly and I might be able to tell you the corresponding IDebugEventCallback2.Event GUIDs.
You probably got off on the wrong foot here, the IDebugXxx interfaces were really intended to create your own debugging engine. Still useful perhaps to see what is going on in the existing engine, you are suppose to use QueryInterface() to discover the specific interface that matches the event. Like IDebugEngineCreateEvent2, IDebugProcessCreateEvent2, IDebugProcessDestroyEvent2, etcetera. There are a bunch of them, they are listed in the VSSDK\VisualStudioIntegration\Common\Inc\msdbg.h header and include their IID.
Best thing to do is peek at this sample, it shows how to crack the event notification into the specific interfaces. The AD7Events.cs source file shows the wrappers. Do keep in mind that this sample was made to show how to create an engine, not how to use the one already built into VS.
But yes, you are not going to get a "continue debug" event out of this. A debugging engine does not need that event since it is already responsible for taking care of that by itself. It already knows when it calls IDebugProgram3::Continue().
Surely what you are looking for is IVsDebugger.AdviseDebuggerEvents(). That's the one that tells you what the built-in debugger is doing. You need to pass an object of a class that implements IVsDebuggerEvents, your OnModeChanged() method will be called with a DBGMODE notification. I don't see a lot of fantastic examples that demonstrate usage, this web page might be helpful.
You know the one I mean:
Is there a way to disable this?
I'm writing an application to automatically test a large number of Excel spreadsheets which are used in a critical environment. Many of these sheets do crazy things which crash Excel. When Excel crashes I want it to terminate ASAP and without user-intervention.
I definitely do not want to re-start excel.
I do not want the excel.exe process to hang-around waiting for somebody to click on "Don't Send"
And I never never want to report the details of my crash to Microsoft!
It a system service that you can easily turn off
Turn off Error Reporting in Microsoft Windows XP Professional
If that doesn't work go to Control Panel / Admin tools / Services and stop and disable the "Error Reporting Service"
Can you somehow detect that Excel has crashed? You can use TerminateProcess function after that, which removes the process for good. There's an article about it on Raymond Chen's blog.
On Windows XP when a process crashes, we get a dialog box with a link:
"To view technical information about the error report, click here."
The "click here" link brings up a whole lot of information in a window, but no obvious way to save it to a file. Is there a way? It would be very nice to be able to send that data to several different external vendors we're working with.
The only other option I see in the dialog box is to send it to Microsoft, but this crash is likely not Microsoft's fault and there is no reason to send it to them.
If you are a company, you can register with Microsoft to be able to download WER reports.
As of when you see this dialog box, you should still be able to manually attach a debugger (e.g. Visual Studio) to the crashing process and take a look at any available exception records. Alternatively, I believe you should be able to register Visual Studio to handle these crashes instead of the normal error reporting mechanism. This article seems to have more information about that option:
http://msdn.microsoft.com/en-us/library/5hs4b7a6.aspx
Hope this helps...
Maybe a bit late for '08 question, but anyway, you may use Error Report Grabber software for this task