Wpf: Microsoft.WindowsDesktop.App (latest runtime) 5.0.0-preview.8.20330.4 cannot display

[wli3]

• .NET Core Version: Microsoft.WindowsDesktop.App 5.0.0-preview.8.20330.4
• Windows version: (winver) 18363.900

• Does the bug reproduce also in WPF for .NET Framework 4.8?: No

  Problem description:
  Run sample WPF-Samples\Data Binding\SortFilter\ on Microsoft.WindowsDesktop.App 5.0.0-preview.8.20330.4 cannot display

  Actual behavior:

I only get a tiny window

Expected behavior:

Minimal repro:

dotnet run on WPF-Samples\Data Binding\SortFilter with the latest SDK

I made sure this is not a tooling problem.

I use dotnet build on an older SDK 5.0.100-preview.4.20258.7 (will repro use the higher SDK 5.0.100-preview.8.20351.5).

And install Microsoft.WindowsDesktop.App 5.0.0-preview.8.20330.4 and Microsoft.NETCore.App 5.0.0-preview.8.20328.6 on my machine.

Double click on the exe. It works since it runs on the lower runtime. Change the SortFilter.runtimeconfig.json to the following. Then double click. You will only see the tiny window

{
  "runtimeOptions": {
    "tfm": "net5.0",
    "framework": {
      "name": "Microsoft.WindowsDesktop.App",
      "version": "5.0.0-preview.8.20330.4"
    }
  }
}

[ryalanms]

5.0.100-preview.6.20325.9 and 5.0.100-preview.7.20357.1 are working: repros on 5.0.0-preview.8.20328.6.

Replacing \Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.0-preview.8.20328.6 coreclr.dll and clrjit.dll with Preview7 versions fixes the regression.

Repros with the default WPF template (impacts all WPF applications):

dotnet new wpf
dotnet run

Windows have a client area height of 0.

cc: @jeffschwMSFT @fabiant3 @SamBent

[jeffschwMSFT]

@mangod9 can you ask someone take a look?

[mangod9]

@ryalanms I am able to repro it, to make diagnosing quicker is there a specific property/field on the window which doesnt seem to be initialized correctly? That would help narrow down where the issue might be. I looked at the System.Windows.Window._size and System.Windows.Window._desiredSize and they seem to have reasonable values. Thx

[ryalanms]

PresentationFramework.dll!System.Windows.Window.SetupInitialState(double requestedTop, double requestedLeft, double requestedWidth, double requestedHeight) Line 2730 C#
PresentationFramework.dll!System.Windows.Window.CreateSourceWindow(bool duringShow) Line 2508 C#
PresentationFramework.dll!System.Windows.Window.CreateSourceWindowDuringShow() Line 2366 C#
PresentationFramework.dll!System.Windows.Window.SafeCreateWindowDuringShow() Line 5244 C#
PresentationFramework.dll!System.Windows.Window.ShowHelper(object booleanBox) Line 5339 C#
...
WindowsBase.dll!MS.Win32.HwndWrapper.WndProc(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam, ref bool handled) Line 297 C#
WindowsBase.dll!MS.Win32.HwndSubclass.DispatcherCallbackOperation(object o) Line 429 C#

I'm not seeing any obviously bad values in the parameters of the p/invoke calls for win32 class registration, Window creation, or size/placement (SetWindowPos).

• sizeDeviceUnits {525,350} System.Windows.Size
  Height 350 double
  IsEmpty false bool
  Width 525 double
  _height 350 double
  _width 525 double

  requestedWidth  525 double
  requestedHeight 350 double
  

Inspecting the Window with Spy++ shows that the client area height is 0. Unhelpful, I know. I'll keep looking.

[mangod9]

ok thanks @ryalanms. Is this the right windows api which would set the window size. Perhaps we could check if there is some marshalling issue if the values on the managed side look correct.

[ryalanms]

@mangod9: Yes, that is correct. SetWindowPos will eventually be called to set the Window size.

[mangod9]

@AaronRobinsonMSFT fyi..

[AaronRobinsonMSFT]

@mangod9 I don't _think_ this is a P/Invoke issue - at least not with SetWindowPos(). I am simply going on the fact that all the values appear to be present. I am not sure they are placed where they need to be since that would be a JIT decision.

The generated code for the dispatch in question is the following:

00007FFA8FD07D4F 48 8B 4D B8          mov         rcx,qword ptr [rbp-48h]  
00007FFA8FD07D53 48 8B 55 B0          mov         rdx,qword ptr [rbp-50h]  
00007FFA8FD07D57 4C 8B C3             mov         r8,rbx  
00007FFA8FD07D5A 4D 8B CE             mov         r9,r14  
00007FFA8FD07D5D 4C 8B 55 A8          mov         r10,qword ptr [rbp-58h]  
00007FFA8FD07D61 4C 89 95 78 FF FF FF mov         qword ptr [rbp-88h],r10  
00007FFA8FD07D68 4C 8D 15 0B 00 00 00 lea         r10,[7FFA8FD07D7Ah]  
00007FFA8FD07D6F 4C 89 55 90          mov         qword ptr [rbp-70h],r10  
00007FFA8FD07D73 41 C6 47 0C 00       mov         byte ptr [r15+0Ch],0  
00007FFA8FD07D78 FF D0                call        rax  

This follows the x64 calling convention - RCX, RDX, R8, R9, spill to stack.

RCX = 0000000001500D32 RDX = 0000000000000000
R8  = 00000000000000EA R9  = 00000000000000EA
RSP = 0000002CA917C208

0x0000002CA917C208  00007ffa8fd07d7a  z}Ð.ú...
0x0000002CA917C210  0000002ca917c258  XÂ.©,...
0x0000002CA917C218  00007ffa8f0878c0  Àx..ú...
0x0000002CA917C220  0000021b03146c60  `l......
0x0000002CA917C228  cccccccccccccccc  ÌÌÌÌÌÌÌÌ
0x0000002CA917C230  000000000000020d  ........
0x0000002CA917C238  000000000000015e  ^.......
0x0000002CA917C240  0000000000000014  ........

The dispatch call should be: SetWindowPos(0x1500D32, 0x0, 0xEA, 0xEA, 0x20d, 0x15e, 0x14)

Values 0x20d = 525 and 0x15e = 350 - which correspond to the window size. All this means is that the data is there, not that it is on the stack where it should be. I will start comparing against the working version and see if I can find a difference between the version above.

[AaronRobinsonMSFT]

@mangod9 Here is a comparison between the two scenarios. The generated code is slightly different. I don't know how important r11 is though. Let me know if I am misinterpreting this and should look further.

.NET Core 3.1

00007FFA8F2FD38F 48 8B 4D B8          mov         rcx,qword ptr [rbp-48h]  
00007FFA8F2FD393 48 8B 55 B0          mov         rdx,qword ptr [rbp-50h]  
00007FFA8F2FD397 4C 8B C3             mov         r8,rbx  
00007FFA8F2FD39A 4D 8B CE             mov         r9,r14  
00007FFA8F2FD39D 41 BB 18 00 00 00    mov         r11d,18h  
00007FFA8F2FD3A3 4C 8B 55 A8          mov         r10,qword ptr [rbp-58h]  
00007FFA8F2FD3A7 4C 89 95 78 FF FF FF mov         qword ptr [rbp-88h],r10  
00007FFA8F2FD3AE 4C 8D 15 0B 00 00 00 lea         r10,[7FFA8F2FD3C0h]  
00007FFA8F2FD3B5 4C 89 55 90          mov         qword ptr [rbp-70h],r10  
00007FFA8F2FD3B9 41 C6 47 0C 00       mov         byte ptr [r15+0Ch],0  
00007FFA8F2FD3BE FF D0                call        rax

First call:

RAX = 00007FFB51CB32E0 RBX = 000000000000004E RCX = 0000000000B40984 RDX = 0000000000000000 RSI = 000000C155DDD650 RDI = 000000C155DDD640 R8  = 000000000000004E R9  = 000000000000004E R10 = 00007FFA8F2FD3C0 R11 = 0000000000000018 R12 = 0000000000000014 R13 = 000000000000015E R14 = 000000000000004E R15 = 000002565979DB90 RIP = 00007FFB51CB32E0 RSP = 000000C155DDD508 RBP = 000000C155DDD5F0 EFL = 00000200 

0x000000C155DDD508  00007ffa8f2fd3c0  ÀÓ/.ú...
0x000000C155DDD510  000002565b5ced58  Xí\[V...
0x000000C155DDD518  000000000000020d  ........
0x000000C155DDD520  0000000000000000  ........
0x000000C155DDD528  000002566b3adcf0  ðÜ:kV...
0x000000C155DDD530  000000000000020d  ........
0x000000C155DDD538  000000000000015e  ^.......
0x000000C155DDD540  0000000000000014  ........

Second call:

RAX = 00007FFB51CB32E0 RBX = 0000000000000000 RCX = 0000000000B40984 RDX = 0000000000000000 RSI = 000000C155DDD8F0 RDI = 000000C155DDD8E0 R8  = 0000000000000000 R9  = 0000000000000000 R10 = 00007FFA8F2FD3C0 R11 = 0000000000000018 R12 = 0000000000000037 R13 = 0000000000000000 R14 = 0000000000000000 R15 = 000002565979DB90 RIP = 00007FFB51CB32E0 RSP = 000000C155DDD7A8 RBP = 000000C155DDD890 EFL = 00000200 

0x000000C155DDD7A8  00007ffa8f2fd3c0  ÀÓ/.ú...
0x000000C155DDD7B0  000002565b41f5d0  ÐõA[V...
0x000000C155DDD7B8  0000000000000001  ........
0x000000C155DDD7C0  0000000000000000  ........
0x000000C155DDD7C8  000002566b3adcf0  ðÜ:kV...
0x000000C155DDD7D0  0000000000000000  ........
0x000000C155DDD7D8  0000000000000000  ........
0x000000C155DDD7E0  0000000000000037  7.......

.NET 5.0 Preview 8

00007FFA8FCD7A7F 48 8B 4D B8          mov         rcx,qword ptr [rbp-48h]  
00007FFA8FCD7A83 48 8B 55 B0          mov         rdx,qword ptr [rbp-50h]  
00007FFA8FCD7A87 4C 8B C3             mov         r8,rbx  
00007FFA8FCD7A8A 4D 8B CE             mov         r9,r14  
00007FFA8FCD7A8D 4C 8B 55 A8          mov         r10,qword ptr [rbp-58h]  
00007FFA8FCD7A91 4C 89 95 78 FF FF FF mov         qword ptr [rbp-88h],r10  
00007FFA8FCD7A98 4C 8D 15 0B 00 00 00 lea         r10,[7FFA8FCD7AAAh]  
00007FFA8FCD7A9F 4C 89 55 90          mov         qword ptr [rbp-70h],r10  
00007FFA8FCD7AA3 41 C6 47 0C 00       mov         byte ptr [r15+0Ch],0  
00007FFA8FCD7AA8 FF D0                call        rax 

First call:

RAX = 00007FFB51CB32E0 RBX = 000000000000009C RCX = 00000000014A0798 RDX = 0000000000000000 RSI = 0000004978D7C440 RDI = 0000004978D7C430 R8  = 000000000000009C R9  = 000000000000009C R10 = 00007FFA8FCD7AAA R11 = 0000000000440444 R12 = 0000000000000014 R13 = 000000000000015E R14 = 000000000000009C R15 = 000002319B7C44B0 RIP = 00007FFB51CB32E0 RSP = 0000004978D7C2F8 RBP = 0000004978D7C3E0 EFL = 00000204 

0x0000004978D7C2F8  00007ffa8fcd7aaa  ªzÍ.ú...
0x0000004978D7C300  0000004978d7c348  HÃ×xI...
0x0000004978D7C308  00007ffa8f0678c0  Àx..ú...
0x0000004978D7C310  000002319b7c44b0  °D|.1...
0x0000004978D7C318  cccccccccccccccc  ÌÌÌÌÌÌÌÌ
0x0000004978D7C320  000000000000020d  ........
0x0000004978D7C328  000000000000015e  ^.......
0x0000004978D7C330  0000000000000014  ........

Second call:

RAX = 00007FFB51CB32E0 RBX = 0000000000000000 RCX = 00000000014A0798 RDX = 0000000000000000 RSI = 0000004978D7C6D0 RDI = 0000004978D7C6C0 R8  = 0000000000000000 R9  = 0000000000000000 R10 = 00007FFA8FCD7AAA R11 = 0000000000440444 R12 = 0000000000000037 R13 = 0000000000000000 R14 = 0000000000000000 R15 = 000002319B7C44B0 RIP = 00007FFB51CB32E0 RSP = 0000004978D7C588 RBP = 0000004978D7C670 EFL = 00000200 

0x0000004978D7C588  00007ffa8fcd7aaa  ªzÍ.ú...
0x0000004978D7C590  0000004978d7c5d8  ØÅ×xI...
0x0000004978D7C598  00007ffa8f0678c0  Àx..ú...
0x0000004978D7C5A0  cccccccccccccccc  ÌÌÌÌÌÌÌÌ
0x0000004978D7C5A8  cccccccccccccccc  ÌÌÌÌÌÌÌÌ
0x0000004978D7C5B0  0000000000000000  ........
0x0000004978D7C5B8  0000000000000000  ........
0x0000004978D7C5C0  0000000000000037  7.......

[jeffschwMSFT]

@AndyAyersMS @BruceForstall @JulieLeeMSFT

[mangod9]

thanks for investigating @AaronRobinsonMSFT. Yeah these appear to be correct. @ryalanms, is this the only place the size is set? Or per your previous comment is the client area height specified some place else? Just want to ensure we are going down the right path to determine what is going on.

[AndyAyersMS]

Bruce and I are happy to help, let us know when/if it makes sense to get us more directly involved.

[mangod9]

Thanks @AndyAyersMS. I believe it would make sense to understand from WPF which precise API(s) are not working as expected. From the initial look doesnt look like SetWindowPos is affected. But it might be worth taking a pre-emptive look at whether the code generated for PresentationFramework.dll!System.Windows.Window.SetupInitialState is any different between preview7 and preview8.

[BruceForstall]

@AaronRobinsonMSFT r11 (on x64) is a GenericPInvokeCalliHelper VASigCookie Parameter, that is, a hidden "cookie argument" for calli pinvoke calls. Is that what we have here? In that case, presumably some pinvoke stub is expecting to see that r11 value.

[vatsan-madhavan]

I've a feeling you're all looking for an x64 (or a 64-bit) problem. Someone should try to repro this on x86 (my hasty 2 min check shows me that it doesn't repro on x86) 😉

[AaronRobinsonMSFT]

@AaronRobinsonMSFT r11 (on x64) is a GenericPInvokeCalliHelper VASigCookie Parameter, that is, a hidden "cookie argument" for calli pinvoke calls. Is that what we have here? In that case, presumably some pinvoke stub is expecting to see that r11 value.

@BruceForstall I don't think so in this case. The call rax in the example above is the actual call to the native function within the stub. Setting that register prior to calling SetWindowPos doesn't seem to be needed in the native call.

[vatsan-madhavan]

If SetWindowPos (or P/Invokes in general) has a problem, then why isn't WinForms also broken by this (or is it) ?

[AaronRobinsonMSFT]

@vatsan-madhavan That is a good question and something I was going to propose. In this case it was very simple to check the codege so I made the sanity check. I agree with you that it does seem related to any interop at the P/Invoke stub gen time or else many more things would be broken in this area.

[AndyAyersMS]

Did we establish if this repros on x64, or is it an x86 only issue?

[AndyAyersMS]

(my hasty 2 min check shows me that it doesn't repro on x86)

Ah, so it is only x64.

[AndyAyersMS]

@BruceForstall and I working on this now... will update status in a bit.

[AndyAyersMS]

Strongly suspect this is a jit issue. Does not require optimization to repro. We have a suspect change in mind. Bisecting now to confirm.

[AndyAyersMS]

Looks like it was dotnet/runtime#38316. We're going to look at reverting this, and in parallel track down where it went wrong.

[jkotas]

r11 (on x64)

This was stack size for SQL hosting. It was removed by https://github.com/dotnet/coreclr/pull/27069

[AndyAyersMS]

We are going to disable the problematic optimization for now, and work on fixing it afterwards.

I would like to run the fix through more WPF tests to make sure nothing else comes up. @dotnet/dotnet-wpf can you recommend something?

[AndyAyersMS]

Also pinging @dotnet/wpf-developers (realizing it's almost exactly the same folks...)

We have a fix/workaround merged into the runtime repo, so in a day or two please install a new nightly build and let us know if anything else seems amiss.

[AndyAyersMS]

please install a new nightly build and let us know if anything else seems amiss.

Latest nightly builds should have the fix; @wli3 or @dotnet/wpf-developers can you confirm?

[mangod9]

Hey @wli3 @ryalanms, would you be able to please validate the latest p8 builds to ensure the issue is fixed?

[wli3]

I tried yesterday with the lastest SDK master. It is still repros. Could you confirm the latest bit flowed to SDK? Or ping me when it is done and build is available

[ryalanms]

The issue appears to be fixed in dotnet-sdk-5.0.100-preview.8.20363.2-win-x64. Thank you for the fast investigation and fix.

The test team is running a test pass with this version of the SDK and will have more detailed results by tomorrow morning. Thanks.

[ryalanms]

Validation succeeded: Windows 7, Blue, Server 2012, Win10 RS3/4/6, and Server 2016 (all x64).

[mangod9]

Thanks for confirming. Assume its ok to close this issue now?

[JulieLeeMSFT]

@wli3 @ryalanms, Tests and verification were successful. Let's close this ticket.

[ryalanms]

Thanks, everyone.