Microsoft.WindowsDesktop.App (latest runtime) 5.0.0-preview.8.20330.4 cannot display #3226

wli3 · 2020-07-07T19:39:05Z

.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"
    }
  }
}

The text was updated successfully, but these errors were encountered:

ryalanms · 2020-07-07T19:59:55Z

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 · 2020-07-08T17:49:12Z

@mangod9 can you ask someone take a look?

mangod9 · 2020-07-08T18:52:16Z

@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 · 2020-07-08T23:31:28Z

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 · 2020-07-09T00:24:00Z

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 · 2020-07-09T16:59:30Z

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

mangod9 · 2020-07-09T18:02:04Z

@AaronRobinsonMSFT fyi..

AaronRobinsonMSFT · 2020-07-09T19:29:17Z

@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 · 2020-07-09T19:49:13Z

@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 · 2020-07-09T19:53:53Z

@AndyAyersMS @BruceForstall @JulieLeeMSFT

mangod9 · 2020-07-09T19:54:23Z

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 · 2020-07-09T20:48:27Z

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

mangod9 · 2020-07-09T21:10:53Z

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 · 2020-07-09T21:22:26Z

@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 · 2020-07-09T21:33:43Z

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 · 2020-07-09T21:39:40Z

@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 · 2020-07-09T21:49:15Z

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

AaronRobinsonMSFT · 2020-07-09T22:04:38Z

@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 · 2020-07-09T23:52:36Z

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

AndyAyersMS · 2020-07-10T00:09:35Z

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

Ah, so it is only x64.

AndyAyersMS · 2020-07-10T00:36:05Z

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

AndyAyersMS · 2020-07-10T00:53:25Z

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 · 2020-07-10T01:18:41Z

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 · 2020-07-10T01:31:36Z

r11 (on x64)

This was stack size for SQL hosting. It was removed by dotnet/coreclr#27069

AndyAyersMS · 2020-07-10T18:34:06Z

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 · 2020-07-11T00:21:13Z

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 · 2020-07-14T00:28:44Z

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 · 2020-07-15T17:18:54Z

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

wli3 · 2020-07-16T04:47:46Z

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 · 2020-07-16T05:35:24Z

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 · 2020-07-16T17:19:43Z

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

mangod9 · 2020-07-16T17:37:08Z

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

JulieLeeMSFT · 2020-08-07T20:16:04Z

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

ryalanms · 2020-08-24T20:08:27Z

Thanks, everyone.

ryalanms added urgent status: This issue needs immediate attention regression status: This issue is a regression from a previous build or release labels Jul 8, 2020

fabiant3 assigned mangod9 Jul 9, 2020

AaronRobinsonMSFT mentioned this issue Jul 9, 2020

Implicit conversion from uint32& to uint32* should be reconsidered dotnet/runtime#39040

Closed

sandreenko mentioned this issue Jul 10, 2020

Fix STOREIND optimization. dotnet/runtime#39066

Merged

AndyAyersMS mentioned this issue Jul 10, 2020

JIT: retype byrefs passed to unmanaged callers as native int dotnet/runtime#39105

Merged

mangod9 mentioned this issue Jul 17, 2020

Crossgen2 fails with TableIndexOutOfRangeException dotnet/runtime#39493

Closed

ryalanms closed this as completed Aug 24, 2020

ghost locked as resolved and limited conversation to collaborators Apr 11, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Microsoft.WindowsDesktop.App (latest runtime) 5.0.0-preview.8.20330.4 cannot display #3226

Microsoft.WindowsDesktop.App (latest runtime) 5.0.0-preview.8.20330.4 cannot display #3226

wli3 commented Jul 7, 2020

ryalanms commented Jul 7, 2020 •

edited

Loading

jeffschwMSFT commented Jul 8, 2020

mangod9 commented Jul 8, 2020

ryalanms commented Jul 8, 2020 •

edited

Loading

mangod9 commented Jul 9, 2020

ryalanms commented Jul 9, 2020

mangod9 commented Jul 9, 2020

AaronRobinsonMSFT commented Jul 9, 2020

AaronRobinsonMSFT commented Jul 9, 2020

jeffschwMSFT commented Jul 9, 2020

mangod9 commented Jul 9, 2020

AndyAyersMS commented Jul 9, 2020

mangod9 commented Jul 9, 2020

BruceForstall commented Jul 9, 2020

vatsan-madhavan commented Jul 9, 2020 •

edited

Loading

AaronRobinsonMSFT commented Jul 9, 2020

vatsan-madhavan commented Jul 9, 2020 •

edited

Loading

AaronRobinsonMSFT commented Jul 9, 2020

AndyAyersMS commented Jul 9, 2020

AndyAyersMS commented Jul 10, 2020

AndyAyersMS commented Jul 10, 2020

AndyAyersMS commented Jul 10, 2020

AndyAyersMS commented Jul 10, 2020

jkotas commented Jul 10, 2020

AndyAyersMS commented Jul 10, 2020

AndyAyersMS commented Jul 11, 2020

AndyAyersMS commented Jul 14, 2020

mangod9 commented Jul 15, 2020

wli3 commented Jul 16, 2020

ryalanms commented Jul 16, 2020

ryalanms commented Jul 16, 2020

mangod9 commented Jul 16, 2020

JulieLeeMSFT commented Aug 7, 2020

ryalanms commented Aug 24, 2020

Microsoft.WindowsDesktop.App (latest runtime) 5.0.0-preview.8.20330.4 cannot display #3226

Microsoft.WindowsDesktop.App (latest runtime) 5.0.0-preview.8.20330.4 cannot display #3226

Comments

wli3 commented Jul 7, 2020

ryalanms commented Jul 7, 2020 • edited Loading

jeffschwMSFT commented Jul 8, 2020

mangod9 commented Jul 8, 2020

ryalanms commented Jul 8, 2020 • edited Loading

mangod9 commented Jul 9, 2020

ryalanms commented Jul 9, 2020

mangod9 commented Jul 9, 2020

AaronRobinsonMSFT commented Jul 9, 2020

AaronRobinsonMSFT commented Jul 9, 2020

jeffschwMSFT commented Jul 9, 2020

mangod9 commented Jul 9, 2020

AndyAyersMS commented Jul 9, 2020

mangod9 commented Jul 9, 2020

BruceForstall commented Jul 9, 2020

vatsan-madhavan commented Jul 9, 2020 • edited Loading

AaronRobinsonMSFT commented Jul 9, 2020

vatsan-madhavan commented Jul 9, 2020 • edited Loading

AaronRobinsonMSFT commented Jul 9, 2020

AndyAyersMS commented Jul 9, 2020

AndyAyersMS commented Jul 10, 2020

AndyAyersMS commented Jul 10, 2020

AndyAyersMS commented Jul 10, 2020

AndyAyersMS commented Jul 10, 2020

jkotas commented Jul 10, 2020

AndyAyersMS commented Jul 10, 2020

AndyAyersMS commented Jul 11, 2020

AndyAyersMS commented Jul 14, 2020

mangod9 commented Jul 15, 2020

wli3 commented Jul 16, 2020

ryalanms commented Jul 16, 2020

ryalanms commented Jul 16, 2020

mangod9 commented Jul 16, 2020

JulieLeeMSFT commented Aug 7, 2020

ryalanms commented Aug 24, 2020

ryalanms commented Jul 7, 2020 •

edited

Loading

ryalanms commented Jul 8, 2020 •

edited

Loading

vatsan-madhavan commented Jul 9, 2020 •

edited

Loading

vatsan-madhavan commented Jul 9, 2020 •

edited

Loading