HiDPI Display w/Scaling Can Cause App Freeze on Launch

[nicholashead]

Upon launch, I see the main screen but after a second or so it greys out and Windows pops up the unresponsive app dialog.

I tried uninstalling and reinstalling, and also deleting the local/roaming folders and reinstalling, still no joy.

[RickStrahl]

Hi Nicholas.

Just double checks clearing out install completely on two different machines, but I can't duplicate this behavior both from the latest download or from Chocolatey. Any more info might help:

• .NET Version installed (latest version requires .NET 4.71)
• Version of MM? Latest is 1.15

I did have a problem with a bad addin in the pre-release earlier that exhibited the behavior you're seeing, but it sounds like you cleared both the install folder and the %AppData%MarkdownMonster folder? If not maybe try renaming the Addins folder there to make sure it's not an addin that's failing.

Best thing for a clean install is this (sound like you already did all this but just to be sure):

• Uninstall MM
• Check in %localappdata%\MarkdownMonster - it should be gone, but if it isn't delete it
• Rename %appdata%\MarkdownMonster to something else
• Reinstall MM (either from Chocolatey or from the Download)

[nicholashead]

Hi Rick,

It's the latest off chocolatey - actually used that to reinstall. And I have the latest .NET version(s) installed (I'm a developer myself!)

Yep, I cleared the %AppData%\MarkdownMonster folder - and its actually not being re-gen'd even after running the app and it freezing.

And yeah, I did exactly what you stated for a clean install (wiped local and roaming markdown monster folders, and reinstalled via chocolatey). I'm only seeing the issue on one of my machines. I wonder if I can attach a debugger to the process...

[RickStrahl]

Thanks for your patience and reporting here...

Yes you can attach a debugger. MM ships with the main PDB file. But I suspect the problem is related to one of the addins perhaps and if so the PDB won't help much.

If it's just on one machine any idea what might be different? If the %appdata% \MarkdownMonster folder doesn't get created that would make me think about permissions or maybe AntiVirus preventing the write operation there? MM doesn't create the folder during install but creates it the first time the app runs and then creates all the related configuration files as it goes. If AV monitors disk, perhaps it's not allowing writing there? (which is weird since it is AppData were you're supposed to write data).

[AngryTrashPanda]

I am having a similar issue, one machine works fine, the other it does not. The only obvious difference between the two machines is that the machine the app freezes on has the VS 2019 preview installed.

[RickStrahl]

@AngryTrashPanda I wouldn't think that VS 2019 makes a difference. I don't think it installs any special system components that would affect the launching of the app. I have it installed on my machine and it still works.

Not discounting that it's happening and it's really quite annoying that it just dies without anything going into the logs which seems to indicate it's failing on an secondary thread right at startup before the infrastructure has initialized properly.

My guess it happens during addin-loading and one of the addins is crashing, but there are safeguards for this during startup - it just looks like they are not getting triggered.

[RickStrahl]

If you have issues with failing, I've addd some additional error checking into the addin load process. I've pushed up 1.15.2 (from the download page Get Latest Pre-Release).

[AngryTrashPanda]

The 1.52.2 Pre-Release still does the same, but this time it doesn't load the UI at all, a black box is all I get.

[RickStrahl]

I believe that might be a different problem. This might be related to #136 (which primarily seems to affect NVidia Quaddro cards).

Can you try turning off Hardware Accelleration in Tools -> Settings:

  "DisableHardwareAcceleration": true

Is this a new install or are you ugprading from an earlier versions? Just curious if this worked before or is just failing now?

[AngryTrashPanda]

New Install, same PC that was freezing before, I did an uninstall and cleared the appdata folders before installing the preview. Before the preview the UI would load before it did the lockup/freeze. The GPU in this machine is a GTX 1050.

[RickStrahl]

Hey thanks for sticking with this. Appreciate the patience. So far these have been the only two reports I've had about this and I can see that most users (new and old) are running the current version fine, so this seems to be definitely isolated to specific configuration.

Is there anything in the error log? (in %appdata%\Markdown Monster\MarkdownMonsterErrors.txt)

Can you try the 1.15.2.3 preview? Just to be sure you're on the latest build. 1.15.2 had a couple updates after the initial publish so there might be some ambiguity.

[acopernic]

No doubt. There's a problem with latest version (stable and not). By installing an old one (1.12) no problem at all but these 2/3 latest version are totally messy.

[RickStrahl]

One last thing here to check. The latest version of MM (1.15) requires .NET 4.71 or later . If running an older version it's possible that there will be startup failures.

There is startup checking for that, however it's possible that whatever failure is happening is perhaps occurring before it ever hits even that start up check code.

[AngryTrashPanda]

I installed the 1.15.2.4 preview, same deal. No error log file is being generated. I downloaded the repository and ran it with vs2017, It doesnt throw any exceptions, slightly different result when the app runs. The only part of the UI that renders past the splash is the markdown preview window, the rest is transparent.

I tried running Markdown Monster with the Nvidia GTX gpu disabled, using the Intel GPU instead, got the same result.

As far as I can tell the Addins are loading correctly, at least this is what I gathered from stepping through the AddinManager.

I ran the .net runtime installer just to see if I somehow didn't already have it, and was greeted with ".NET Framework 4.7.2 or a later update is already installed on this computer."

[AngryTrashPanda]

I grabbed the zip of 1.14.15 and built/ran it, this one runs just fine and loads the ui without any freezing.

[RickStrahl]

@AngryTrashPanda Thanks for checking.

So there are two things that have changed:

• Switching to 4.7.1.
• Slight tweak to the offscreen rendering/move into view logic

It could be the latter and some oddball timing issue, but I would think that if there's a failure there it would show for everyone and not just a few people.

When the window doesn't show - can you tell whether the Windows is actually there and a) invisible, or b) offscreen? Does the Window menu on the taskbar work to move the window into place I wonder?

Thanks for chekcing - I can't debug this myself since I can't duplicate it on any of my 4 machines I test on.

[AngryTrashPanda]

The window is there, it is just a black box with a black outline around it. Would having a High DPI screen impact the offscreen rendering?

[RickStrahl]

Yup that's it... I was able to duplicate it on one of my machines:

• Works fine in 100% resolution (4k)
• Locks up in 150% scaling

Locks up during startup with varying degrees of change.

Tried to pin it down and checked my code changes since the last 14.x version that worked, but none of those changes affected anything.

However went back and rolled back to .NET 4.6.2 and now the app runs fine again on the scaled display.

Just pushed up 1.15.3 - give that a try and see if that works for you - I suspect it will.

If for some reason it doesn't can you try switching to 100% to verify whether that works?

[acopernic]

YEEEEEES... Problem solved. BRAVO

[AngryTrashPanda]

Yup works good now. Thanks Rick!

[RickStrahl]

Yay!!!! Thank you all for your patience - I appreciate you sticking with me to track this down! I know it's a pain to debug somebody else's product especially when it fails hard like this...

So just to close the circle here:

• The issue occurs due to High DPI Scaling (100% scaling)
• Occurs when MM is compiled to .NET 4.7.1 - does not when compiled to 4.6.2 (reverted now)

Apparently it's not a 100% repo case to run in a scaled display - two of my 4 test machines had no problem running at 150%, but the other two did lock up.

I took a little bit of time trying to debug this hooking up the debugger, but found no user or even system .NET code locking. In fact it looks like the App itself is sitting idle but just not getting events pumped to it.

It looks like this might be related to this WPF issue: https://github.com/Microsoft/dotnet/issues/604

I will revisit this in the future perhaps, but rolling back to 4.6.2 is not a big deal at this time. The reason for rolling forward to 4.7.1 - better support for .NET Standard libraries -turned out to be a bust. So nothing is really lost with this backstep.

[vatsan-madhavan]

I tried 1.14.15 on .NET 4.8 runtime on 100% and 150% monitors - no hangs. Should I have seen hangs on that version?

Are there any hang-dumps available to debug?

Since the issue says that the problem is related to high DPI scaling - is this in any way at all related to enabling per-monitor scaling in an application manifest? It doesn't seem like that from the description so far, and the application HWND's seem to be only system-aware (default for WPF) and not per-monitor aware.

/cc @SamBent

[SamBent]

If it's really Microsoft/dotnet#604, you should see ResolveStarMaxDiscrepancy on the stack, and not "app sitting idle". That bug only showed up in HDPI and was quite sensitive to its environment (it involved rounding errors), which would fit the different results on different machines observations. It was fixed in 4.8, and you can also work around it by setting the app-context switch cited therein.

If it's not the 604 bug, please let us know.

[RickStrahl]

@vatsan-madhavan 1.14.15 was fine - it's 1.15 - 1.15.2.x that was running compiled against .NET 4.7.1 and those were the problem. Latest version is is 1.15.3 and anything newer is back compiled against 4.6.2 and that seems to have fixed it. I pulled those two releases on Chocolatey since they are going to give most people trouble, but if anybody wants to look at them you can grab them from:

https://github.com/RickStrahl/MarkdownMonsterReleases/tree/master/v1.15

@SamBent The call stack is empty and the main threads sits on the App.Run(). Code fires in my main window though, but before the window activates it locks up when running in anything but 100% scaling on my dev machine with 4.7.1. Revert to 4.6.2 and the same code runs no problem.

The main thread shows the app sitting on App.Run() when I click in. Call stack only shows Main. All the other threads (with the exception of one of my own threads that waits on a Pipe (Pipemanager thread below)) all other threads are either inactive or native.

Another interesting tidbit here: On this machine, scaling at 150% fails. Scaling at %125 works.

@vatsan-madhavan As to per monitor scaling: MM does some special stuff with this as I have a screen capture utility that needs to highlight pixel based windows/objects. Honestly I can't remember all the details but I can probably turn that off now and just use the default behavior. Unfortunately that had no effect.

However adding this to AssemblyInfo.cs:

[assembly: DisableDpiAwareness]

Makes the app start properly even in scaled mode with 4.7.1.

[RickStrahl]

Reopening to keep the discussion going.

[vatsan-madhavan]

@RickStrahl, thanks, I’ll check out 1.15.

If you are able to reproduce it every time on your dev machine, would you try to get a time travel trace of the hang?

[RickStrahl]

@vatsan-madhavan Ah a good excuse to try out that feature, huh? I'll give it a shot.

[RickStrahl]

So I gave WinDbg a try but it seems when launching with WinDbg the app hangs immediately under any circumstances Scaling or no. I can see MM getting launched (Exe shows in TaskMan), but WinDbg stops and logs show nothing. Other apps seem to keep on logging, but MM immediately stops. Same executable runs though.

[SamBent]

@RickStrahl The callstack in your screenshot only shows your code, hiding all the interesting stuff under "[External Code]". Go to Debug/Options and turn off "Enable Just My Code", then try again. Everything else you've said sounds consistent with the ReolveStarMaxDiscrepancy bug, so I'd expect you'll see that in the full callstack.

[vatsan-madhavan]

I tried v1.15 on a couple of different machines today, with no hang (they all have 3 monitors with 100, 150 and 125% scaling).

As well as disabling Just My Code, perhaps also enabling native debugging could show us more interesting information in the call stack.

[RickStrahl]

@SamBent here's the full call stack if that helps:

[RickStrahl]

@vatsan-madhavan Just to be sure I also went back and installed 1.5 explicitly and sure enough I can make it fail consistently. It only fails at 150% and greater, 125% works oddly. Maybe try even higher scale if you have a hi-res (4k?) display. I'm running on a 4k screen here.

Loading got a little further this time loading the form but still hangs up before the form gets focus:

I do have code in the start up that checks for display scaling info and based on that resizes or moves the main form if it's scaled or placed off the desktop somewhere. Removed that code just in case but the result is still the same.

Also with the debugger attached and waiting long enough (about 3-4 minutes I'd say) this pops up:

That brings back memories :-) Maybe Don Box and "I'm dreaming in COM"...

[nicholashead]

Just wanted to confirm that my computer with 4K display using scaling is indeed the one where the freeze was happening. My other computer does not use scaling at all and it was still working. Great job troubleshooting, everyone!

[SamBent]

@RickStrahl That callstack definitely implicates the Grid layout bug. It's a hard infinite loop, which explains the debug assistant's complaint. It's fixed in .Net 4.8, which explains why Vatsan can't repro. It has nothing to do with per-monitor DPI, but everything to do with roundoff error arising from the high DPI and UseLayoutRounding. It's extremely sensitive to the numbers involved, which explains why you see it on some machines and DPI scales but not others.

I added a summary of all the Grid hangs to Microsoft/dotnet#604. Hopefully to dispel any further confusion.

I think everything is explained now. No further action needed.