ASP.Net Core - Application Insights - Stack Trace - asp.net-core

I'm setting up a pretty simple ASP.Net Core (2.2) MVC Web App. I want to be able to see any application errors (500s) and what caused them so it seems like Application Insights is the place to look.
If I go into Application Insights / Failures (Operations Tab - see screenshot below), I'm able to see a graph/count of all the 500 errors. I can click on "DRILL INTO" button and see a lof of the details (Event Time, Request Name, etc...) but cannot seem to get any details on the actual cause of the error / line number.
Basically, I have the exact same problem as this person:
Azure Monitor / Application Insights not showing stack trace for errors
(my screenshots look identical).
When I drill down to the exception details, I get something like this:
I'm want to get something like this:
I did see info on adding Application Insights via Nuget to my solution and putting
services.AddApplicationInsightsTelemetry();
into the Startup/ConfigureServices method.
I also see that you can look at Kudu logs, etc... but I really want this all to be easily accessible in Application Insights.
Any suggestions?

OK - I think I solved my own problem. Turns out I had added Serilog a while back (sort of forgot about that) and it was capturing all the errors before getting to AI. When I removed the Serilog configuration code from Program.cs and Startup.cs, the application exceptions started showing up in Application Insights / Failures along with the full Call Stack. Thanks for your suggestions!

A 500 Internal server error suggests you are looking for the stack trace to identify what went wrong and where. No code has been provided in your example but you will need to surround your code with a try catch and then log the exception to get the stack trace or you can use the TelemetryClient as below:
var telemetry = new TelemetryClient();
...
try
{ ...
}
catch (Exception ex)
{
// Set up some properties:
var properties = new Dictionary <string, string>
{{"Game", currentGame.Name}};
var measurements = new Dictionary <string, double>
{{"Users", currentGame.Users.Count}};
// Send the exception telemetry:
telemetry.TrackException(ex, properties, measurements);
}
Further information can be found at Microsoft

Related

CefSharp.BrowserSubProcess.Core WCF pipe failure

Our application is using CefSharp version 73.1.130. The issue only occurs on a small number of internal workstations within our organization. Worth noting, we are also seeing the same error with CefSharp version 92. Another strange thing is that it the issue is consistent, but only when the web apps are launched through certain navigations. Other navigations work consistently for these users.
We use RegisterJsObject to register a javascript object with browser. If I understand correctly, asynchronous binding is preferred moving forward.
The issue presents as strange/unexpected behavior in the hosted web application due to failure to retrieve context from the host WinForms application. The behavior would suggest a failure to register/bind the js object with the RegisterJsObject method. However, that method is not throwing an exception.
Enabled Cef logging showed the following error:
ERROR:JavascriptRootObjectWrapper.cpp(34)] IBrowserProcess is null, unable to bind object
After looking into the code, it appears the location that the value pointed to by "IBrowserProcess" is set is in WcfEnabledSubProcess::OnBrowserCreated (https://github.com/cefsharp/CefSharp/blob/cefsharp/73/CefSharp.BrowserSubprocess.Core/WcfEnabledSubProcess.cpp). I was able to build CefSharp and add additional logging to that method.
On my workstation (I'm not affected by the issue), I get through OnBrowserCreated with no exceptions. However, on my coworkers workstation I see the following line is failing:
...
channelFactory->Open();
auto browserProcess = channelFactory->CreateChannel();
auto clientChannel = ((IClientChannel^)browserProcess);
try
{
clientChannel->Open(); <-- FAILS
browser->ChannelFactory = channelFactory;
browser->BrowserProcess = browserProcess;
}
catch (Exception^)
{
}
}
With the error:
There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)
Has anyone seen this issue before? I'm not sure how much this will help, but does anyone know if it's possible to enable WCF tracing with the CefSharp.BrowserSubProcess.exe. I have been trying this, but no luck so far.

ExceptionFilterAttribute may not be logging exceptions in ApplicationInsights

Do exceptions that are filtered with a custom ExceptionFilterAttribute logged to Application Insights?
I want to return a custom DTO in my custom ExceptionFilterAttribute filter, but I think exceptions are no longer logged into ApplicationInsights after that. This is for .NET Core 3.0.
I added a line with:
this.telemetryClient.TrackException(context.Exception);
to make sure I can see the exception but I'm not sure if my exceptions are logged twice now.
Does anyone know if ApplicationInsights will log exception if they enter ExceptionFilterAttribute? I can't find documentation for this.
I'm calling just in case also:
base.OnException(context);
Does anyone know if ApplicationInsights will log exception if they
enter ExceptionFilterAttribute?
Yes, it will log the exceptions, so you do not need to add this line of code this.telemetryClient.TrackException(context.Exception);. Just using base.OnException(context); is ok.
You can see this GitHub issue for the similar issue, the reason is that "With new Ilogger enablement by default, exceptions are automatically reported by application insights.".
I also check it via a simple test, the test result as below:

Using Serilog from within WCF

I'm using Serilog from within my website & web API all good.
Now I want to use Serilog from within WCF.
But when I new up a LoggerConfiguration and create a logger from within WCF, the logging doesn't seem to work? Eg nothing is being output to the text file.
var seriLog = new LoggerConfiguration()
.WriteTo.File(#"C:\Serilogs\myapp.txt")
.CreateLogger();
seriLog.Debug("log message");
Ultimately I want to write to Seq from within the WCF service.
What am I missing or doing wrong?
Has anyone got some working code samples of how this would be done?
Are there tricks to using the Serilog/Seq stack from within WCF?
There are a couple of things to that come to mind-
First, is the setup code here being executed only once, i.e. at application startup, so there is exactly one logger pointing to the text file? Only one instance of the logger can use the file at a time.
Next, is the process running with permission to access the file?
Last, is the file open e.g. in Notepad or another app that might have it locked?
If none of these spark any ideas, you can set up Serilog's self-log before configuring the logger:
SelfLog.Out = Console.Error;
This should get shown in the VS debugger, so if Serilog's catching and suppressing any exceptions you should see them.
If you can't run it in a debugger, try:
SelfLog.Out = File.OpenText(#"C:\loglog.txt");
Sometimes I find running the app under the debugger with "Break on all exceptions" enabled can be a quick way to get to the bottom of it, too (Ctrl-D,E -> CLR Exceptions [x] Thrown, [x] Unhandled).

WP7 and WCF Services: Fast app switching

I'm currently building a WP7 app that consumes WCF Data Services hosted on a web server. What I'd like to deal with is
cathayService.ServiceException += (sender, e) =>
{
Debug.WriteLine(e.Exception.ToString());
MessageBox.Show(e.Exception.ToString(), "Service Error", MessageBoxButton.OK);
};
The service exception triggers if I have a lack of internet connectivity. It also triggers when I face with fast app switching. How'd I be able to differentiate the source of the ServiceException?
Hope someone can give me an idea... Many thanks! :)
[It's unclear if you are getting a ServiceException instance, or if you are referring to the ServiceException event in some places above]
Check the exception you get - if it's typed as ThreadAbortException, that means you are being switched out. If you actually get a ServiceException thrown, check it's inner Exception and see if THAT guy is ThreadAbortException.
My suggestion is that you don't hook that event though and instead use the actual callback events on the WCF client to check the .Error property of the EventArgs you get back.

Throwing exception in WCF service operation, anything to look out?

I am just learning WCF and wrote a Windows Service hosting a WCF service. Ever since I started it in service.msc in the remote server (physically remote, and very slow) I think I have already hit and fixed like a hundred errors here and there already. I am now finally stuck.
At this point, I have enabled tracing and message logging. The first and only function call looks like this:
[OperationContract]
public MyServiceResponse ConnectToAXDynamicsViaDotNET2BusinessConnectorWithSadFace()
{
try
{
throw new NotImplemented();
}
catch(Exception ex)
{
return new MyServiceResponse(ex, ex.Message);
}
}
[DataContract]
public class MyServiceResponse
{
// ...
}
Upon calling the operation, the client just sits and waits until timeout. Checking the trace, it records my thrown exception. So it makes me wonder if WCF actually blocks there and ignore my catch clause.
I then tested with just a simple return value without throwing and it FINALLY works.
My question is, how then can I make the above scenario work, ie. catch the exception and return a sensible result back to client? Maybe it's just the tracing that blocks me, but I want to enable tracing during this whole debugging process otherwise it's really hard to work.
Thanks for your precious help!
EDIT: Sorry, I found this right after I posted this question. Happens all the time: http://msdn.microsoft.com/en-us/library/ee942778.aspx but I have yet to read it as I got to run off now. Not sure it it will solve my problem.
Risk being downvoted, but just for documentation sake and general usefulness of having this question:
Through reading the FaultException handling articles, I guess the above behavior is due to Exception class not serializable. And the service silently disconnects itself without returning any error messages eventhough the "send (unknown) faults to client" is enabled. As for why it does so, I have no idea yet. Will update if I find out more.
I have since changed to throw new FaultException() instead of returning my own MyServiceResponses.