Symbols aren't loaded sometimes

[macaba]

As per title - symbols aren't loaded sometimes (making a typical ~1000KB json.gz file into a ~160KB file that isn't very useful in the viewer).

I tried various things, such as rebuilding the application-to-be-profiled, deleting the symbol cache folder that I could find (in appdata). The only thing that made it work again is restarting my PC. Perhaps #13 had a similar resolution.

I noticed that after the restart, ultra showed many more symbols loaded, perhaps there could be a flag to not use the cached symbols?

[xoofx]

Thanks for the report. I can't tell exactly what happens here, as I haven't experienced this myself yet.

I noticed that after the restart, ultra showed many more symbols loaded, perhaps there could be a flag to not use the cached symbols?

Caching is supposed to work mostly for symbols that are downloaded on internet. Disabling it would cause massive slowdown when resolving symbols.

Symbols aren't loaded sometimes

Could you elaborate exactly which symbols? Which assemblies/native DLLs are actually concerned? Is it user code (your assemblies), NuGet assemblies, OS DLLs? Anything that could help narrow down the issue.

There is a possibility to output what is happening in the symbol resolver, it's verbose so I haven't added it by default, but I could add a mode to store the log on disk to investigate such issues.

[xoofx]

Also, is it when you are profiling an app directly launched via ultra or a long running process?

[macaba]

There isn't a log file so I don't know exactly what symbols aren't loaded. The profiler view is really minimal, only showing memory allocations, so perhaps I could say "all of them".
Would this be obvious from the json files? I can email those over.

I am profiling an app directly launched, i.e. ultra.exe profile -- TS.NET.Engine.exe -seconds 10

[xoofx]

There isn't a log file so I don't know exactly what symbols aren't loaded. The profiler view is really minimal, only showing memory allocations, so perhaps I could say "all of them".
Would this be obvious from the json files? I can email those over.

The JSON won't help. The log file doesn't exist today because as I said, I don't write it for symbols 🙂
At least you should have native callstacks (kernel functions called...etc.)

I am profiling an app directly launched, i.e. ultra.exe profile -- TS.NET.Engine.exe -seconds 10

Whenever I test ultra, I'm testing it against https://github.com/xoofx/ultra/tree/main/src/Ultra.Example which works. Could you try it on your machine?

What is different with this TS.NET.Engine.exe? What is the .NET/OS version?

[macaba]

I have found steps to reproduce:

• Run ultra to normal completion (JSON has all the data)
• Run ultra, use CTRL+C to stop it early (JSON is missing data <-- to be expected?)
• Run ultra to normal completion (JSON is missing data <-- the issue)
• Restart PC
• Run ultra to normal completion (JSON has all the data)

TS.NET.Engine is a console app, source

[macaba]

.NET 9, Windows 10.

[macaba]

I tried Ultra.Example on both .NET 8 and .NET 9, and my steps to reproduce did not work. I am out of ideas for now.

[xoofx]

Run ultra, use CTRL+C to stop it early (JSON is missing data <-- to be expected?)

This is not expected. Are you hitting CTRL+C more than one time?
you can pass --verbose to ultra e.g. ultra --verbose profile ... to get more details and can post them here.

TS.NET.Engine is a console app, source

Cool, I can try from there directly, let's see

[xoofx]

TS.NET.Engine is a console app, source

Running with TS.NET.Engine.exe -seconds 10 and it says:

Another instance of TS.NET.Engine is already running.

[macaba]

Open up thunderscope.yaml and change line 32 to HardwareDriver: Simulator

[macaba]

A new day allowed me to look at this with fresh critical eyes: I realized my muscle memory was opening an Administrator PowerShell prompt, not an Administrator Command prompt.

I found that CTRL+C in CMD is fine, and continues working.
Then I did CTRL+C in PS and it causes failure from that point on (and even when opening a new PS or CMD after that point, it's still broken).

[xoofx]

I found that CTRL+C in CMD is fine, and continues working.
Then I did CTRL+C in PS and it causes failure from that point on (and even when opening a new PS or CMD after that point, it's still broken).

When you say PS, is it pwsh (the .NET core version) or the old PS Windows?

I'm only running from pwsh and CTRL+C is working fine there.

[Genmutant]

It seems for me it's also not loading symbols (despite showing that it does), so all the threads in the view are completely empty. The only thing shown are JitCompile and Allocations. It worked a single time, and I can't reproduce it anymore. So far I tried emptying the SymbolCache, copying my program pdb into the SymbolCache folder, and changing the symbol type (tried FULL and PORTABLE). Also tried running it from PS and CMD.
The same problem exists with the Ultra.Example program.
My system is also Win 10 and dotnet 9, though Ultra.Example ran as a dotnet 8 program,

Is there a way I can try to collect some useful information for you?