While testing an ASP.NET application with perfmon, we find that the following field is non-zero:
ASP.NET Apps v2.0.50727 > Errors During Preprocessing
Documentation says that this field is "The number of errors that occurred during parsing, excluding compilation and run-time errors."
However, I have not been able to track down why this is happening.
Any clues on where these actual preprocessing errors are logged? Or how to enable logging so we can fix these errors?
One thing I would try is to precompile your application from the command line using aspnet_compiler. e.g. from a VS command window, try something like:
aspnet_compiler -v / -p c:\PathToYourAppRoot
At runtime, there is some fallback behavior which may mask some errors. But when running aspnet_compiler, it should be catching and displaying any error that it encounters.
If that doesn't help, another thing you can try to isolate the issue is figure out after what specific http request the counter goes up. e.g. does it go up as soon as you send the first request, or only after hitting specific URLs?
Check your event viewer. They should be showing up there. You may also want to look at the link below for info on how to send the event logs to other places (db, email, etc...)
http://www.asp.net/(S(sf10gzjodvrpce55el2p5cnk))/learn/hosting/tutorial-13-cs.aspx
Related
I am a total noob with Application Insights, and sadly for a whole day of trying I have been unable to get it working at all. I tried with the following code:
this.telemetryClient = new TelemetryClient(TelemetryConfiguration.CreateDefault());
this.telemetryClient.TrackTrace($"Test", Microsoft.ApplicationInsights.DataContracts.SeverityLevel.Warning);
But when I go to the application insights window and show all telemetry from the current debugging session there is nothing logged. One user said an ApplicationInsights.config file is missing (and that an empty one would do fine for debugging), I created one but it changed nothing.
Then I tried the simplest console app I could find - https://learn.microsoft.com/en-us/azure/azure-monitor/app/console . I don't have an instrumentation key, and from the hundreds of forums I read today, if you leave it blank it should still appear in the debugging telemetry. Alas, still nothing in Application Insights.
How can I get it working? I just want to see a single Trace message in the Visual Studio Application Insights window when queried for "debugging telemetry".
I used to work on this stuff and the way it generally works, the extension tries to figure out if it should watch for debug output, and if it doesn't recognize the project type, we do nothing (to avoid doign work in the debugger when we don't need to). in this case, console apps aren't a "known" supported project type.
IIRC, to get debug output I believe you need to do 2 things, of which you've done 1:
1) add an ApplicationInsights.config file at the root of that project
2) add an application insight resource id to to the csproj:
<ApplicationInsightsResourceId>/subscriptions/abc</ApplicationInsightsResourceId>
i don't think the resource id even needs to be valid, but if it does even better, because then other things can light up, like exceptions codelens, various links to the portal/etc.
you migth only need to do #2?
i think that if you do the above and restart vs/reload the solution, you should see the debugger integration try to do work when the debugger starts. (it used to!)
I have had a few reports of a message box showing up on application launch with the following contents:
[Arg_NullReferenceException]
Arguments:
Debugging resource strings are unavailable. Often the key and arguments provide
sufficient information to diagnose the problem. See http://go.microsoft...
I understand the link provided gives me the exception detail, and I obviously have a null ref somewhere. I haven't been able to reproduce this, so I am trying to find where this message is being thrown and hopefully add some error handling.
Is this specific message box something baked into Silverlight, or is it following whatever exception handling is in place when such an exception occurs? In the app constructor, I have
this.UnhandledException += this.Application_UnhandledException;
which is:
private void Application_UnhandledException(object sender,
ApplicationUnhandledExceptionEventArgs e)
{
MessageBox.Show(e.ExceptionObject.Message + "\n" + e.ExceptionObject.StackTrace);
}
So it looks like this message box is not coming from the Application_UnhandledException or it would have a message, newline, then a stack trace. So now my two options for how this message box is being generated are: 1) Silverlight is doing it in the background, or 2) this is coming from an existing catch block, although I have found none that would display in this way.
I'm doing offline caching of XAPs in Isolated Storage using OfflineCatalog, which involves some asynchronous WebClient downloads and fall-backs to Isolated Storage when requests fail. It makes sense that a null ref might be happening somewhere in this process.
To summarize, I'm wanting to add some exception handling for this Null Reference, but cannot reproduce it locally, and cannot find where it may be coming from. If this is coming from an unhandled exception, why does it not display the message and stack trace as specified?
The error message occurs if the machine does not have Silverlight SDK installed normally.
To debug similar browser side exceptions, it is common practice to use Visual Studio. If you cannot use VS, simply use WinDbg to attach to the browser process.
Currently I'm programming an application to record data. The data will be stored clustered to a file.
This data can be analyzed by the user or the program displaying the data. By analyzing large amount of data the program ends suddenly, i.e. there is no exception, any other error message or any process at the task manager just no more program.
By analyzing the program with perfmon I found lots of i/o (460 events/s and 15MB/s) at this moment as expected. Is there any limit reading data from different places of a file? (I'm seeking positions and read complete clusters.)
Make sure you're wrapping your code with a try..catch. Then set a break point in the catch. (#Paolo makes a good point, be sure the try..catch is in the thread that is doing the work.)
Also, you could try setting visual studio to break on all exceptions. "Debug" / "Exceptions" / Select relevant "Thrown" check boxes.
Also, try checking the Event Viewer for some hints.
Finally, you can also do Debug.WriteLine or Trace.WriteLine in certain places (esp if running on a system w/o visual studio) and monitor output with Sysinternals DebugView
Note: Be sure to make code production qual (i.e., add logging, program defensively, etc) after/while finding the source of the issue.
Use try..catch.
Subscribe to AppDomain.CurrentDomain.UnhandledExceptions.
Use NLog.
Watch the process' working set.
Recently deployed a project into production and have run into the "Invalid postback or callback argument" error. We haven't encountered this in testing at all and after some research have found that the problem occurs in the following situation:
Old version is published and accessed.
New version is published and accessed without clearing the Temporary Files.
Drop down is changed twice. (The first time everything works fine.)
The fix for the clients that have called in has been to clear their temporary internet files but this isn't the ideal fix. Can anyone think of a reason why this would be happening and stop happening after the temp files have been cleared?
BTW: The app is ASP.NET 3.5 written in C#. We're using a javascript call back in this particular control that's causing this issue.
We didn't want to use the "enableEventValidation=false" trick as this isn't a consistent issue. From pretty early on, we were able to fix the issue case by case by clearing the temp files.
After some more looking today it was suggested that we rename our js file and behold, the issue is resolved locally. Seems that each user has had our old js file stored.
As to why it was throwing the "Invalid Postback" rather than a javascript error, we're not sure. There are other ways of specifying the version number in the script tags but for now we opted for the rename.
Since you mentioned that you're using a javascript callback, this may be related to event validation. If that's so, there is a workaround for that problem which is adding the following line to web.config:
<pages enableEventValidation="false"/>
So that, event validation is disabled in your pages. To turn it off is not recommended for security reasons because it verifies that arguments are originated by the server control.
You can get detailed information here about why this error occurs.
I am using this - otherwise excellent - vb tab control in one of my c# apps. When the app using it is installed on another machine, Windows tells the user in its usual friendly and descriptive manner that "The application encountered a problem and needs to close". I guess the control has some hidden vb-related dependency, but what can that be?
Any ideas guys?
Since the tab control appears to be managed code as well, your 'crash' is most likely an unhandled .NET exception.
Looking at the error details (by expanding the error dialog using the button provided for that purpose...) should give you the exception message, which should give you an idea of what's going on. If it's a missing dependency DLL, the name should be included in the message.
To get the full exception, including the stack trace, one of the following should work:
Least effort: in the first line of your own managed code, add an unhandled exception handler which shows the full exception in a message box or logs it to a file prior to rethrowing it
Medium effort: attach a debugger to the process on the client machine. If it's on your local network, setting up remote debugging should be trivial, and should also allow you to debug exceptions that occur prior to your first line of code executing (which may very well be the case if the error is binding-related...)
Most effort: obtain the crash dump file from the client machine, and look at the managed exception using Windbg and the SOS debugging extensions. Getting productive with the tools involved will take some time, but on the plus side will teach you valuable debug ninja skills that will allow you to tackle pretty much any 'mysterious crash'...
BTW, all standard 'VB dependencies' are part of the default .NET Framework install, so that's not your problem -- only the exact exception (and possibly stack trace) will tell you what's going on.
Click the 'What data does this error report contain?' button and there will be more descriptive info. (i.e. type of the thrown exception, module etc.).
For additional info see Dr. Watson vs. CLR.
Is the dll containing the control distributed with your app? Perhaps you have a dependancy in the GAC thay you are missing?