Infinite Measure/Arrange/Layout/Scroll loop possible with the treeview

[KirillOsenkov]

Since the big treeview is virtualized and variable height (due to the yellow breadcrumb panel at the bottom), it is a recipe for disaster - we can fall into an infinite layout loop in WPF (which is a known problem: https://connect.microsoft.com/VisualStudio/feedback/details/969547/infinite-measure-and-arrange-loop-with-virtualizingstackpanel)

Look into making sure that the treeview height doesn't dance when the selection changes (somehow calm down the layout storm caused by the breadcrumb panel vertical resize).

[KirillOsenkov]

Three pieces of information:

1. There's a setting in app.config that you can enable to record a trace of the measure/scroll activity to a file called ScrollTrace.stf:
   

   MSBuildStructuredLog/src/StructuredLogViewer/App.config

   Lines 10 to 13 in 264d937

   	<!-- uncomment this to trace VirtualizingStackPanel scrolling (will create a file called ScrollTrace.stf) -->
   	<!--<appSettings>
   	<add key="ScrollingTraceTarget" value="treeView" />
   	</appSettings>-->

   
   To investigate this further you need to record that log.

2. This may be already fixed in the latest versions of .NET framework, the bug reproduces in 4.6.01038 but may be fixed in 4.6.01586.

3. For now I've turned off treeview virtualization so the bug shouldn't happen (at the expense of slower treeview operations).

[KirillOsenkov]

I've turned the virtualization back on but added a checkbox to turn it off. If scrolling hangs the viewer just uncheck the checkbox.

[kikootwo]

We are encountering this issue. We have a large treeview, and with Virtualization we can follow a specific scrolling behavior and can consistently reproduce this issue.

Are there any known workarounds (other than disabling virtualization)? And are there any updates on the status of this issue?

[KirillOsenkov]

If you can repro consistently, would you be able to follow the instructions above and record the trace and attach it here? I can then route to the WPF team.

What version of .NET Framework are you using?

[kikootwo]

Do I need to be using MSBuildStructuredLog to create the log?
I am using a treeview in my own program and receiving the issue.

The project is on .NET Framework 4.6.1, but I tried the recently released 4.8 in hopes that it would be fixed; it was not.

[KirillOsenkov]

You could use your own program to reproduce and record a trace.

Instructions from @SamBent:

==========

We’ve fixed many issues in VirtualizingStackPanel since the one you’ve mentioned. Does your hang repro on latest .Net? If so, open a bug.

The hangs, crashes, and incorrect scrolling bugs in VSP have the “feature” that same surface symptoms (hot codepath, callstack, scroll offset) can arise from different root causes. So just because your bug looks like one we’ve fixed doesn’t mean it’s the same. If you’ve stumbled on a new root cause, we’re very interested in fixing it.

Recent versions of .Net have some built-in tracing for these kinds of problems. Add the highlighted line (and the surrounding tags if needed) to MyApp.exe.config, replacing “MyTreeView” by the name of the problematic control (assuming you’ve named it: ). Then run MyApp.exe so as to repro the problem. Afterwards there will be a file named ScrollTrace.stf (or similar) in your app folder. Attach it to the bug (or send it to me).

                <configuration>
                                <appSettings>
                                                <add key=”ScrollingTraceTarget” value=”MyTreeView” />
                                </appSettings>
                </configuration>

BTW, “01038” isn’t a useful version number. Use this page to determine which version of .Net is on your machine.
https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed

[KirillOsenkov]

I found a relatively simple repro:

0. Install the MSBuild Structured Log Viewer from http://msbuildlog.com or build it yourself

1. Start the MSBuild Structured Log Viewer and make sure that both these checkboxes are checked:
   

2. Open this .binlog:
   https://www.dropbox.com/s/5md183dpzj3svmm/msbuild.binlog?dl=0

3. Search for "StyleCop"

4. Scroll the results down to the first Message in the long list:
   

5. Click on the Message

6. Scroll the main treeview up with the scrollwheel

[KirillOsenkov]

Personal notes:

C:\Users\Kirill\AppData\Local\SourceServer\VSTFDEVDIV_DEVDIV2\DevDiv\FX\Rel\Net48Rel1Last_B\wpf\src\Framework\System\Windows\Controls\VirtualizingStackPanel.cs\1745372\VirtualizingStackPanel.cs
Changeset 1728280: 11/28/2018 2:58 PM 448747 Infinite Layout Loop when ListBox is positioned outside the view
Changeset 1744308: 11/19/2019 3:00 PM [DevDiv VSO: 1024122][2020.01 C] DTS: WPF TreeView, virtualization, scroll, freeze
Changeset 1747153: 04/22/2020 12:04 PM [DevDiv VSO:1081806] DTS: [4.8] WPF Tree View Freeze / Hang #2490
https://github.com/dotnet/wpf/pull/2271/files

[KirillOsenkov]

http://.../DevDiv2/DevDiv/_versionControl/changeset/1728280
http://.../DevDiv2/DevDiv/_versionControl/changeset/1744308
http://.../DevDiv2/DevDiv/_versionControl/changeset/1747153

[KirillOsenkov]

Workaround: Uncheck this checkbox:

[SamBent]

@KirillOsenkov - All the known hangs in TreeView are fixed as of the latest .NET updates, applying to .NET 4.7.x and .NET 4.8 and deployed in July or August 2020 (depending on your OS and your Windows Update settings). So if you have those updates and you still need to uncheck the box, it's an "unknown" hang and you should report it to https://github.com/dotnet/wpf/issues and send me the crash dump and .stf files as described earlier.

[KirillOsenkov]

@SamBent thanks Sam, I saw you've fixed another one of these in April I think. I myself have been dogfooding with virtualization and haven't seen it since. So maybe the customer who reported it doesn't have the latest framework update.

I'll keep an eye out for more of these issues.

I admire your perseverance in fixing these and it is much appreciated. I know how insanely difficult this area is. Thanks so much for your efforts here!

[jairbubbles]

@SamBent I have the latest Windows updates, .NET Framework 4.8 (528372 in the registry). How can I know I have the fix from July or August 2020 you're mentioning?

[SamBent]

@jairbubbles Go to Settings -> Update & Security -> Windows Update -> View Update History. Look for a "Quality Update" entry of the form "2020-10 Cumulative Update for .NET Framework 3.5 and 4.8 for Windows 20H2 for X64 (KB4578968)" - you should see several of these with different dates, OS, KB numbers. If you have one dated 2020-08 or later, you should have the fix.

If in doubt, follow an update link to the description page. The left column of this page has links to previous updates for your OS. Look in these to find the update where the fix first appeared. This depends on your OS; for example on my machine I tracked back to "July 31, 2020 — KB4562899 Cumulative Update Preview for .NET Framework 3.5, 4.8 for Windows 10 Version 2004 and Windows Server, version 2004" (here), which lists a WPF fix:

• Addresses an issue with a hang while scrolling a TreeView whose tree is non-uniform, in the sense thata given node's children govern subtrees whose sizes are quite different.

These updates are cumulative - if you have one issued any time after the fix, you have the fix.

[jairbubbles]

@SamBent I couldn't find a KB corresponding exactly, only security related KB (last one from 16/10/2020)
I have Windows 20H2 (19042.572) so maybe the quality patch is already included?
(KB4562899 is for Windows 2004, KB4562901 is for Windows 1809)

Please also note that I still have the issue if I uncheck the box "Enable tree virtualization" but it's still an infinite loop in a VirtualizingStackPanel. Maybe it' just a different situation.

[KirillOsenkov]

Have you confirmed it's an infinite loop? Maybe it's just a very long list being laid out? How long have you waited?

[jairbubbles]

Like many many minutes and there is still the VirtualizingStackPanel in the stack trace when I attach the debugger.

[KirillOsenkov]

Would you be able to obtain a scroll trace as per Sam’s instructions in this issue?

[jairbubbles]

@KirillOsenkov This was indeed on the "results" tree, to get the trace I added:

  <appSettings>
    <add key="ScrollingTraceTarget" value="resultsList" />
  </appSettings>

Here is the scroll trace: freeze.zip
(It becomes quickly huge so I tried to exit the app as soon as possible)

[KirillOsenkov]

@SamBent FYI we have a trace above

[SamBent]

@jairbubbles The zip contains only the build log "freeze.binlog". We need "ScrollTrace.stf" and the corresponding .dmp file. Plus a description of what you did while viewing "freeze.binlog" that led to the hang.

[jairbubbles]

@SamBent My bad, I uploaded th wrong zip...

Here is the good one: ScrollTrace.zip

The repro steps are detailed on the other issue: #407

[SamBent]

The .stf trace doesn't match your repro steps. I don't any evidence of "select the last item" or "press Down key"; these wouldn't show up directly in the trace, but it looks like they wouldn't work anyway - the loop is already in effect.

What I see in the trace is three MouseWheelDown commands. The first two scroll the treeview down by 96 pixels, leaving it not quite at the end - there's 2.4 more pixels still left to reveal. The third asks to scroll down by 48 pixels, but we scroll by only 2.4. There's then a check to see if we've scrolled the right amount; the naive answer is "no" because 48 != 2.4, but it's then supposed to recognize that 2.4 put us at the end, which is OK. This didn't work for some reason, and we retry the scroll - but nothing has really changed, so this loops.

The reason @KirillOsenkov and I cannot repro the hang is probably because it's very sensitive to the exact height of your window relative to the data. For example when I view your freeze.binlog, two MouseWheelDowns don't get me near the end - it takes 4 or 5 and even then I still don't end up so close to the end. But the data in the trace is often enough to piece together a repro, by cooking the window height and element height to match yours, and presumably run into the same floating-point rounding issue (which is what I'm guessing is the root cause).

[jairbubbles]

@SamBent You're right I can reproduce by only scrolling with the mouse wheel in the results tree! (But it also works with the down arrow If I do scroll before at the bottom with the scrollbar.)

I I snoop I can see that the tree view dimensions are:

And items in the tree various heights:
=> 17.6
=> 20

[KirillOsenkov]

@jairbubbles thanks for diving so deep to investigate! Can you upload your PresentationFramework.dll? You can use Debug -> Windows -> Modules when you break in VS to get the path it’s being loaded from. This way we’ll know which exact build of WPF you’re running and whether you have all the latest fixes.

[jairbubbles]

@KirillOsenkov Assembly file version is 4.8.4220.0

[jairbubbles]

By the way, do you plan to redistribute the application as a .NET Core / .NET 5 (self-contained) app in a near-future?

[KirillOsenkov]

I want to, but it needs time and I’m very busy these days.

It’ll be easier if you upload the actual binary, I need the MVID and the Pdb Guid and age to look up the Pdb and matching source. Unfortunately the dll isn’t stamped with a commit.

[KirillOsenkov]

Or if you want you can run the Pdb tool yourself and tell me what the Pdb guid is: https://github.com/KirillOsenkov/MetadataTools

[jairbubbles]

Here you go:

Debug directory entry: CodeView
Guid:     962b878c-cf94-4a63-95d5-3e4bfebded2e
Age:      1
Pdb path: PresentationFramework.pdb
Stamp:    5F03B15D

[jairbubbles]

Please also note @KirillOsenkov that I compiled the application as .NET Core app and I can't reproduce the issue. That might indeed indicates that the fix is not yet on .NET Framework.

(BTW I pushed a draft MR #411, compiling to .NET Core is pretty straight forward but I guess all the work will be on the CI side)

[KirillOsenkov]

Interesting, my .dll version is 4.8.4270.0 and my Pdb Guid is

Guid:     fa522614-8c3b-4529-82ad-109c5b31eeda
Age:      1
Pdb path: PresentationFramework.pdb
Stamp:    5F52B6DB

This makes me think that you don't have the latest version. Unfortunately I wasn't able to track down symbols for your build, so I can't definitively pinpoint the source code it was built from. Not sure why the symbols from your drop aren't published.

Thanks for the .NET Core PR. If you undraft it I'll take it.

[anton-zaicev]

Have same issues (PresentationFramework.dll version is also 4.8.4220.0).
Windows 10 Version 2004, 2020-10 Cumulative Update for .NET installed (KB4578968) as Sam said.
@KirillOsenkov, how did you get 4.8.4270.0 version?

[SamBent]

4.8.4220.0 is the 2020-08 update - it has the latest fixes. 4270 is a later update, containing nothing new that's relevant here.

The latest hang (from #407) apparently has a different root cause from the ones reported here (#21). From my POV, they are different bugs, although I understand that they are both hangs and thus look the same to users. To avoid confusion, I recommend continuing the discussion at #407. (Which I'm about to do...)

[KirillOsenkov]

I'll close this bug as it has been fixed in WPF.

We have another one #407 where we have a fix that should hopefully be released via Windows Update soonish.