I'm trying to figure out a CPU performance problem using PerfView, my application is an Asp.Net Core 2.2 running on IIS. According to this video https://channel9.msdn.com/Series/PerfView-Tutorial/PerfView-Tutorial-2-A-Simple-CPU-Performance-Investigation the "Caller" is the main point to find the performance problem, but in my collections it's showing just a "ROOT" entry and it's not expandable, see:
Any help?
Tks
The view in your screenshot is showing "Methods that call module coreclr <<coreclr?>>" so as you expand the tree, it's showing you what called the current item. ROOT is the end of the line because nothing called that, which is why you can't expand beyond that.
The item above ROOT is the dotnet process that started your assembly.
Related
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
I have a console app, and a class library.
I'm making changes to the class library (adding new methods, changing what methods do, etc) - Just regular stuff - nothing fancy.
In the console app - I'm calling methods from the class library - obviously to test the class library methods - again no rocket science here!
Both projects are targeting Framework 3.5 (This is because I have Sharepoint 2010 being referenced in class library)
Now:
When I debug the app using F5 - I've set a break point in the console app. When it steps through to the class library (using F11) I get a message saying source code has changed in a pretty lengthy dialog. If I click cancel - it then says No source code available.
I have found a work around to right click on project in solution explorer, then select debug -> create new instance.
But this is strange, never had this issue before, what can I do to get the debugger behaving normally. By normally I mean every time I hit F5 it should understand that the source code in the class library will almost surely have changed and I don't want any nags about this, or break point conditions never being met.
On a side note, never had this issue before, so an explanation as to why its happening would help a lot.
Thanks in advance
Update: the short version
Why do I have to manually tell the debugger to "create new instance" everytime I want to debug? If I don't hitting f5 debugs the source code of the last successful debug session.
Maybe your console application doesn't build second project? Try verifying that newest version of library is called.
I get the infamous "Dialogs must be user-initiated" Security Exception when I try to print some stuff in Silverlight. As you can see, the dialog is as user-initiated as can be:
John Papa couldn't help me much out neither, because I don't have any breakpoint set. Mr MSDN thinks it could also be that I'm just taking too long, but this is a demo application just as simple as can be.
Any ideas? I guess it's a Visual Studio quirk, maybe some extensions interfering, as things seems to work when I launch the application outside of it. I first thought maybe the Code Contracts are interfering with their IL weaving, but they are deactivated for this project.
Update: This is just a simple Silverlight application that runs locally from the file system. When I do "Start debugging", Visual Studio creates a hosting HTML file containing the Silverlight app in the Debug resp. Release folder of the project, launches the Internet Explorer with that HTML file and attaches the debugger to it.
Update 2: I also get the same error when I create a web project to host the Silverlight app and create a virtual directory for it on IIS.
I might also want to add that I don't have problems with printing in other Silverlight projects regardless of their hosting scenarios.
Update 3: I downloaded FireFox and it works, I don't get the error when I debug with it. So it seems to have to do with my IE8. I uploaded the solution:
http://dl.dropbox.com/u/10401470/Code/Demos/PrintingDemo.zip
I wonder if anyone can reproduce?
Anyone got an idea to which team I should file a bug report? Silverlight team? IE team? VS Debugger team?
I'm able to reproduce this. You have handled the Click twice, once in XAML another time in code. See your MainPage.xaml
<Button x:Name="PrintButton"
Content="Gotta print 'em!" Margin="8"
Click="PrintButton_Click" />
Don't feel bad about it. I did it last time through a misplaced Print inside a loop.
I've also experienced this strange behaviour. A standard button click event immediately invoking an OpenFileDialog. It would frequently generate the same error when being debugged but would eventually be coaxed in to working when the button is clicked several times.
However when built as a release (or perhaps simply by running the same Xap without a debugger attached to the browser) the problem would go away.
Try to remove
if(SightPaleceListBox.Items.Count > 0)
I had the same problem and found out that the reason was this following line:
cnvsMain.Children.Remove(PrintPagePlaceHolder);
cnvMain is on the page that the user pushed the Print button on (I was trying to remove it from that page in order to add it to the canvas that I was going to print).
My tip: try to comment rows one by one, until you find what row causes the problem. Than try to work around it.
We have a legacy VB6 application which has worked just fine on Windows XP Professional SP 3 until just recently when we added an IE frame control so that we could display static local HTML files on a form. And, it works fine until I go to close the application. And, then it reports the following error message (consistently):
Faulting module ntdll.dll, version 5.1.2600.5755, stamp 49901d48
Here's the reference in the Visual Basic project file:
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll
And we use it by performing the following actions:
Development machine is running Win7 + Vb6 IDE.
Add a component reference to the "Microsoft Internet Controls" located at C:\Windows\SysWow64\ieframe.dll
Place a control on the form at design time.
Show that form modally by calling Form.Show vbModal The error happens when I use the default form instance frmMyForm.Show vbModal as well as when I use a local instance Dim MyForm as New frmMyFormMyForm.Show vbModal
Call WebBrowser.Navigate "staticPage.html"
When the user presses a button, the button click event returns the user choice and the form is disposed of.
Exit the application -- Here's where I get the error.
I've been looking all over the web, and haven't been able to find a whole lot of people still trying to use VB6 in this way. So, I'm wondering if someone might be able to help me on stackoverflow. Any help is much appreciated!
[Update] And, the plot thickens. I made a sample application with just that web component in order to make sure that it was causing the error. But, I didn’t experience the error when it closed like I was when exiting our existing/legacy vb6 application. I'll do a bit more investigating.
A follow up to this in case any runs into the same issue (the original poster and I were coworkers at the time)...
The application was using the VBCorLib library, and some of its string manipulation classes utilized direct memory access incorrectly. Read more at this VBCorLib forum post.
It turns out that the issue was that I was trying to delete the temporary file that the browser had loaded. It works now that I've moved that delete file code to the form unload event.
This is driving us crazy... In VS2010, MVC2 projects, not all projects.... both on a project that was upgraded from 2008/mvc1 and on a brand new project created within 2010/MVC2, we have the following behavior:
1) develop as normal..
2) hit F5 or CTRL-F5 to open up a browser
3) works great!
4) add a CSS file (or JS file or any file, or remove any file) in the project
5) immediately the dialog pops up "WebDev.WebServer20.exe has stopped working"
You have to close the program, and "F5" again - and all is right with the world...
Say we then modify an existing css file. No problem. But adding or removing one, immediate crash.
It seems like the development webserver is "locked on" to the project file and when it detects a change, it dies.
The Event Viewer is pretty unhelpful. The following is logged:
Faulting application WebDev.WebServer20.exe, version 10.0.30319.1, time stamp 0x4ba204ca, faulting module KERNEL32.dll, version 6.0.6001.18215, time stamp 0x49953395, exception code 0xe053534f, fault offset 0x000442eb, process id 0x%9, application start time 0x%10.
This is happening on all of our developer workstations, which include some with Windows Sever 2008, some with Windows XP, and some with Windows 7. All are running VS2010 Premium with ReSharper.
Also, the same thing happens on projects which target the 4.0 framework, only the error message referrs to WebDev.WebServer40.exe instead.
Google has revealed nothing. We've already tried "setting a static port" instead of a dynamic port - no help.
Please help if you can.
So, as it turns out, the problem was due to a certain use of MVCTurbine and StructureMap, but it seems likely that the problem would also occur with other IOC Containers, not just StructureMap.
The author of MVCTurbine has expressed that the fix will be in version 2.2 of that product.
In the meantime, one extra line of code in your Global.asax will solve this problem:
//VNEXT: after Turbine 2.2 we wont need this line anymore...
protected override void ShutdownContext() { CurrentContext = null; ServiceLocator = null; }
This article shows the particular use case we were addressing. The "normal plain vanilla" use of MVCTurbine and StructureMap would not have this problem.
Obviously, great thanks to Javier for being so responsive to help requests!