3

Looking at the sshot from CPU stacks in PerfView I'm not sure how to interpret the first record.

enter image description here

I can't safely exclude the record, because every thread in CallTree starts with this frame. But what's bothering me is why the frame takes exclusive 181 secs and how to work with thre frame.

Should I safely ignore it in CPU Stacks?

What does it do internally that it takes the time (as it is displayed with so much exclusive time)?

Edit

If I choose "no group" (so empty string) in GroupPats part, then the ntdll!RtlUserThreadStart frame is at the end (it "takes" almost no CPU time). There is also a lot of low level function calls that I can't interpret easilly because they are internally called, but in overall view it's much better..

Edit2 (for usr)

I sshoted today PerfView session. It's server application, so there is a lot of threads. So the view is ok for single threads, but not very valuable for my purpose. I wanted to see basically By Name view, but I'm quite unsure what the RtlUserThreadStart there means..

enter image description here

stej
  • 28,745
  • 11
  • 71
  • 104
  • I find Perfview too confusing. I only use it to list the data in Events table. For CPU analysis use WPA: https://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-42-WPT-CPU-Analysis – magicandre1981 Apr 09 '16 at 07:30
  • Ok, thanks. Anyway, I hoped somebody will point me to the right direction. Unfortunatelly perfview looks like interesting tool, but it's almost one man show.. – stej Apr 21 '16 at 06:48
  • I only use Perfview to look for events, here it is much better compared to WPA. For analyzing disk/CPU memory issues I always use WPA. – magicandre1981 Apr 21 '16 at 15:15
  • @stej have you tried to choose "no group" in the GroupPats drop down? Is the RtlUserThreadStart cpu usage still so high? – Sebastian Jun 12 '16 at 16:37
  • @lowleveldesign added comment. It's better although still not perfect. But I can't expect that probably :) – stej Jun 13 '16 at 12:52
  • Are your stacks even valid and not broken? Go to the call tree to make sure it's sensible. There, you should find that the first frame consumes almost no time. – usr Jun 13 '16 at 13:17
  • @usr CallTree is ok if I look by thread, but there is a lot of threads, so this view is not so valuable.. I'll add sshot to the question. – stej Jun 14 '16 at 13:09
  • I usually add "Thread (" to the Grouppats. I never found a need to view per thread information when profiling. – usr Jun 14 '16 at 13:19
  • @usr if if specify `[ASP.NET Just My App] \Temporary ASP.NET Files\->;!dynamicClass.S->;!=>OTHER;Thread (=>TR` then the threads are not grouped, they then appear as `TR << Thread (somenum) CPU=timems >>` etc. And there is still one line per thread. Any example? – stej Jun 15 '16 at 11:33
  • No idea, this should work. I'm not a PerfView expert. Maybe you forgot to press Enter to refresh the view?! Put in the plug :) – usr Jun 15 '16 at 11:35

1 Answers1

1

Windows threads start at a common thread startup wrapper function: RtlUserThreadStart in Ntdll.dll

Methods called by RtlUserThreadStart are by default rolled up because GroupPats is set at "Just My App" at startup of PerfView. Change this to "no grouping" or "group modules" (as documented in the help file) :

enter image description here

Also, if you see question marks inside a method name you can lookup the symbols so the names become meaningful.

enter image description here

buckley
  • 13,690
  • 3
  • 53
  • 61