I am testing the standalone IntelliTrace recorder tool but struggle to use it for post-mortem debugging of a client WPF application.
I managed to record the data using the IntelliTrace recorder. However, when I view the created .itrace file in Visual Studio 2017 15.8.6 Enterprise, I cannot see any references to the code. VS tells me for all events that all threads execute only external or framework code.
The events that have been recorded are mostly WPF button click gestures. Even though the button click method itself is in BCL libraries, I was expecting to see click handler code. Furthermore, I also added a line to throw an exception in my app (which then of course is thrown in the code of the application), but for this, I also cannot see any code.
The collection plan did not make any difference. I was using the builtin ASP.NET Trace collection plan as it is supposed to be verbose, the default plan and a customized plan where I removed everything that is not important for the app under test.
The program database files are located next to the executables as I was executing the program from in its build output directory, so VS should not have any problems finding the pdbs.
The commandline I was using to start the collection is
C:\IntelliTrace\IntelliTraceSC.exe launch /cp:C:\IntelliTrace\collection_plan.ASP.NET.trace.xml /f:C:\IntelliTrace\test.itrace MyApp.exe
Am I missing something? What is required to see the actual code? Currently, I only see the sequence of events, which alone is pretty useless for debugging.
I am using the IntelliTrace collector version 14.0.24720.00.
You have to check your debbuger.
Try Right click on the project and under Configuration Properties -> Debugging there should be a row with Debugger type).
Can you try debugging with the type switched to mixed mode? It seems like you also have managed code running and it may be using the incorrect debugger if it is set to auto.
Are you still getting the same issue?
Also can you try debugging with Just My Code turned off. Tools -> Optio -> Debugging. Make sure Enabled Just My Code is unchecked. Does this issue still appear?
Also, try with:
Debug > Options > General > Uncheck "Enable Just My Code"
All the references that I mention has background in:
https://msdn.microsoft.com/de-de/library/dd264915(v=vs.120)
Hope it fix your issue
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 coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
I'd like to humbly ask: How can I debug a wince executable(.exe) that has been stored on the wince device, using Visual Studio's debugging facility.
As we all know, using VS2005, we can create a Win32 Smart Device Project(.vcproj)，add our source files to it, compile, select a target device, and press F5, then the generated exe will be deployed to the wince device and gets attached to the VS2005 wince debugger. But I'd really like to know, if someone has a wince exe(call it stock) already in his wince-device and have source code corresponding to that exe, HOW DO I start debugging that stock exe directly WITHOUT compiling the source code? I cannot compile the source code perhaps because I'm missing some library source or other reason.
For PC program, I know I can open an exe as a project so to start debugging that exe. I can find the main() function and set a break point on its first statement, then F5 will stop at that break point.
Thank you in advance.
I often run into this problem as well; I wish the "exe project" created would allow changing the debugger to "Smart Device Native Debugger" (or somehow set the platform) -> Let me know if someone knows how to do that.
The two ways I have been able to work around this are:
New Project Method:
Create an empty "Smart Device" project with no source code.
Change the "Configuration Properties > Debugging > Remote Executable" to your "Stock EXE" that you put on the device, ie: \FlashDisk\MyApp.exe
F5 to debug, and choose "Yes" when it says "deployment errors, do you wish to continue".
Attach to Process Method:
Same as above, but, instead of editing "Remote Executable" just start the "Stock EXE" via rapistart.exe / running manually via screen. Then make sure the "Attach to Process" transport is set to "Smart Device" and you should be able to attach.
After this you need to manually load the pdb, choose src files, etc, as you would a normal PC app.
If you want to debug a .NET CF managed application then the following link should help:
http://msdn.microsoft.com/en-us/library/b1ksfbk7%28VS.80%29.aspx
I only used managed .NET CF but I found this link that has loads of goodies on how to debug both managed and native code on a Windows Mobile 5 in VS2005. Most of it should apply to Win CE as well:
http://msdn.microsoft.com/en-us/library/aa446524.aspx
I figure out the method lately after going through quite a lot of reading and experiment(so many tricky points that Microsoft does not clearly document). user2093823 kindly summarized the procedure.
Some historical screen shots:
UPDATE: navigating to the process via menu:DEBUG / Attach Process / iexplore.exe shows "Automatic: Silverlight code". i.e. VS 2010 already attached to the process. Why doesn't it go to debug view?
I have a frustrating debug behaviour going on on my laptop which I'd like to fix. I was following along with the demo called Silverlight TV 46: What's Wrong with my WCF Service?
On my computer, I noticed that putting throw new ArithmeticException() in the RIA service causes the just-in-time debugger to get involved (a bad thing -- I want VS). I can put a break point on the the throw new ArithmeticExpression() line, and VS stops as it normally does. Press F10, and I still get the just-in-time debugger kicking in.
On Yvor's computer (the presenter in the Ch 8 link above), the visual studio debugger kicks in instead of the just-in-time one. What am I doing wrong? Could having Redgate Reflector installed previously have caused this (it is gone now).
ERROR:
Visual Studio Just-In-Time Debugger
Code: 4004
Category: ManagedRuntimeError
Message: System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid.
Check ...
Possible Debuggers:
New instance of MS VS 2010,
New instance of VS 2008.
[checked] Set currently selected debugger as the default.
[unchecked] Manually choose the debugging engines
Action: Hit Yes.
2nd ERROR:
Unable to attach to the crashing process. A debugger is already attached.
I've spent several hours looking for a way to solve this.
Browser is IE9 / Silverlight 4.
Previously, I started starting the silverlight app directly via the VS2010 environment... but then decided to get more deployment compliant (again).
http://msdn.microsoft.com/en-us/library/cc838267(VS.95).aspx
Down the bottom they mention repairing from control panel / VS2010. Did that. Waited for ages, made coffee, did something else. Finally complete. Problem sill there. Included this step just-in-case the fix is cumulative (you get superstitious after a while with these things).
I then deleted zap files, switched startup page from html to the aspx one. Wired aspx to the xap (it wasn't pointing to the /debug/ folder). [note: looks like you can remove the debug via Silverlight Project / build / Output path: Replace Bin\Debug\ with Bin. With Silverlight I feel that the relative Uri path should match up to your html / aspx files no matter what -- wheather you are in Debug or Release.
project properties / Web / Specific Page
debugging works again!
Did .html stop debugging? Casual inspection reveals the same javascript stuff firing up Silverlight. On the surface it looks the same. hmmm. I guess it isn't.
... here are a few extra things to look at for those who still have issues (I may as well list them
while they are fresh in my mind).
project / properties / Web / Debuggers: I now only have Silverlight checked. ASP.Net is not checked any more. (Not sure if this influences my result at this stage)
make sure your web project points to the silverlight project in project / properties / Silverlight Applications. This ensures that the silverlight project's binary "xap" is copied to a folder within the Web Site / Web App. Note: hitting the add button reveals a destination folder (should be ClientBin).
Your build configuration will add an additional sub foler e.g. debug.
Make sure your .aspx or .html files have the right path. For me, I just included the .ClientBin/debug/ folder. I don't think this is deploy friendly, so I will search for a better way later.
IE9 settings.
[X] Disable script debugging.
[X] Disable script debugging (Other)
[ ] Display notification about a script error
[ ] Show friendly HTTP error message
Again, unsure if these later setting have an impact.
Lastly, there's something that I forget about sometimes. Be sure to check Debug VS2010 / Exceptions / Common language Runtime. This ups the ability to catch exceptions.
I had a similar problem, but the above did not resolve it. However, starting the application without debugging (Ctrl-F5) and triggering the exception would allow me to select the Visual Studio instance that I started the application from. Amazingly, I got a sensible stack trace and resolve the problem within a few minutes.
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.