First I'd like to head off the "wait a minute" questions.
Yes, I've read every thread with similar titles and subjects on SO and beyond.
Yes, I'm using the very latest version of SP1 and any potential hotfixes that might be related to this problem.
So, with specificity, here is my problem:
When I'm debugging Silverlight applications and it hits a breakpoint, everything works just fine as long as I use the mouse. I can continue, step, stop debugging, disable and enable breakpoints all just fine -- as long as I do so with the mouse.
But when I use the keyboard, Visual Studio freezes for a number of seconds, sometimes over a minute. This is any use of the keyboard. But after a short time, it starts to work just fine until that debugging session is over. But the next debugging session (regardless of whether I use the same instance of Casini or not) it will do exactly the same thing.
When I say any keyboard use, I mean it. F5 (Continue), Shift-F5 (Stop Debugging), F10 (Step Over), as well as typing in the Immediate window or even hitting the ALT key to highlight the menu.
For instance, if I try to type something in the Immediate window, it freezes for about 15 seconds and then shows the first key and repeats the pattern about 5 times until it releases and everything is just fine.
When I say "freezes" I'm not talking just Visual Studio but it hangs the entire operating system except for my ability to move the mouse. Even so, the mouse cursor remains what it was when it froze regardless of the program it's over, such as the text selector.
It only happens with Silverlight and it doesn't matter which version I use.
Here's what I'm running:
Windows 7 Professional 64-bit, all of the latest updates included, 12 GB RAM & 1.5 TB HD.
Visual Studio 2010 Ultimate with all of the latest updates.
All software is legit and I've already tried removing and/or disabling just about everything that can be removed or disabled, including extensions. I've used Process Explorer from Sysinternals to kill or stop everything I can. I've also tried it on a very simple Silverlight application with nothing more than one line of code that doesn't access anything.
EDIT: Forgot to mention that I also don't have it loading symbols beyond the "Just My Code" that it normally would and I've tried every debug setting that I can think of as well. And Intellitrace is also turned off (since I do have Ultimate), but that makes no difference either.
UPDATE (11/18): It gets more and more odd. I determined that the temporary freeze doesn't occur only when Visual Studio has focus. When VS (during the super-simple Silverlight app) goes into debug mode, any keyboard access AT ALL causes the same effect. SO, it appears that it has to (in some way) be related (at least in part) to my Windows setup, contrary to my assertion in the comments, but I cannot possibly fathom how. And if other programs are doing something when it freezes, the delay is longer (which makes a certain amount of sense with the symptoms). I'm still at a complete loss.
Anyone have any ideas or see this before? It's really frustrating.
I solved the problem.
It turned out to be the LastPass toolbar. It's a very handy thing and I've used it for years without issue. Yeah, yeah, toolbars are evil, I get it. :)
Disabling it in IE fixed the problem completely. I can still use it in FF (which is my main browser anyway except for working for which I use IE) and everything works fine.
Even so, it's bizarre to me that the toolbar would only have an effect when SL debugs. I didn't have an issue with ASP.Net debugging and I didn't any issues when the SL app was actually running, only when I hit a breakpoint AND hit a key within the first 15 seconds or so.
In any case, problem solved and thanks for your suggestions.
Try changing registry setting LowLevelHooksTimeout from 5000 to something low, like 300.
It can be at
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\Control Panel\Desktop
or
HKEY_CURRENT_USER\Control Panel\Desktop
(first setting at Policy key seems to globally override user setting).
Related
I am designing a Windows Form app. I have an MDIParent form that loads in a maximized state, and loads its child forms in a maximized state as well. However, when I open an OpenFileDialog, or any datareader object, the MDIParent shrinks to a smaller size with all its forms and controls.
This solution Opening child form is causing mdiform to change size and shrink does not apply/work in my situation.
Also this solution https://support.microsoft.com/en-nz/help/967173/restoring-a-maximized-or-minimized-mdi-parent-form-causes-its-height-t did not work for me.
Some background: I have seen this behaviour in almost all my WinForm applications but I have never been keen to sort it out. I was able to narrow down to the causes as highlighted above when I started investigate it. Some posts are describing it as a windows bug, but it has existed for as long as the screen resolutions started going above 1024 (VS 2010) for my case. I hoped it is not just a windows bug...
I hoped it is not just a windows bug...
Feature, not a bug, but it is not one that Winforms programmers like very much. Notable is that there have been several questions about mystifying window shrinkage in the past few months. I think it is associated with the release of Win10 Fall Creators edition. It has deep changes to the legacy Win32 api layer and they've caused plenty of upheaval.
In your specific case, the "feature" is enabled by a shell extension. They get injected into your process when you use OpenFileDialog. The one that does this is very, very evil and does something that a shell extension must absolutely never do. It calls SetProcessDPIAware(). Notable is that it might have been written in WPF, it has a very sneaky backdoor to declare itself dpiAware. Just loading the PresentationCore assembly is enough. But not otherwise limited to WPF code, any code can do this and that might have been undetected for a long time.
One way to chase down this evil extension is by using SysInternals' AutoRuns utility. It lets you selectively disable extensions. But there is also a programmer's way, you can debug this in VS.
Use Project > Properties > Debug tab > tick the "Enable native code debugging" checkbox. Named slightly different in old VS versions btw. Then Debug > New Breakpoint > Function Breakpoint. Function name = user32!SetProcessDPIAware, Language = C. You can exercise this in a do-nothing WPF app to ensure that everything is set correctly. For completeness you can also add the breakpoint for SetProcessDPIAwareness, the new flavor.
Press F5 to start debugging and trigger the OpenFileDialog.ShowDialog() call. The breakpoint should now hit, use Debug > Windows > Call Stack to look at the stack trace. You typically will not see anything very recognizable in your case since the evil code lives in a DLL that you don't have a PDB for. But the DLL name and location (visible in Debug > Windows > Modules) ought to be helpful to identify the person you need to file a bug with. Uninstall it if you can live without it.
Last but not least, it is getting pretty important to start creating Winforms apps that are dpiAware so such a bug can never byte. You kick this off by declaring your app to be dpiAware so DPI virtualization is disabled. Plus whatever you need to do in your code to ensure the UI design scales properly.
Observed behaviour (everything here is on Windows 10):
I run Visual Studio (tried 13 and 15, both behave the same) logged into user A
After starting up, VS takes virtually no CPU time (<1%)
I log into user B, without signing out of A
VS imediately starts using A LOT of CPU time (~25% on my 4 cores with hyper threading)
I can go back and forth between A and B, and it goes back and forth between low and high CPU usage
This is all without any projects or files opened, though it also happens in that case.
I noticed this because I was originally investigating similar behaviour of a WPF application (after a user reported this issue).
While trying to isolate the problem, I found that even a completely new WPF project, with just a single empty window, behaves exactly the same (whether or not run through Visual Studio).
Through profiling and debugging I found that the app seems to spend a huge amount of time handling windows messages.
Specifically I found that it seems to be almost exclusively WM_PAINT messages (we are talking easily hundreds or thousands of messages per second - as many as the CPU can handle it seems).
No other programs I have running (chrome, skype, sublime text, ..) behaves this way.
Has anybody else seen this kind of behaviour?
And/or any ideas what could cause this, or how I could investigate this further?
Naturally, I cannot fix Visual Studio (unless the problem is with my setup somehow) but I hope there is something I can do about my WPF application.
As per Hans Passant's suggestion in the comments, I reported this problem to Microsoft here:
http://connect.microsoft.com/VisualStudio/feedback/details/2390593/wpf-apps-use-a-lot-of-cpu-time-when-logged-into-different-user
As it turns out this indeed seems to have been a bug in WPF, which is fixed in the current version of Windows 10 (probably specifically since the Anniversary Update (version 1607)).
Hence the solution: Make sure to update your OS.
TL;DR:
application is built with WPF, running on .Net 3.5
newest and older versions of the app work properly on many different machines
on one specific machine it malfunctions in a strange way:
either does not start, displays black screen instead of "welcome" screen; can't do anything on that black screen
or does start and works properly, until a TextBox is presented and until the user starts entering the text into it; then application immediatelly hangs
Background:
I have built a WPF application on .Net 3.5. I've checked the application on various machines with different OS, ranging from Windows XP up to Windows 7 - and it runs fine, no bugs, etc. It also works fine on my client's several target machines, XP and W7 included again.
However, on one machine, it suddenly ceased to work. My client sent me the machine so I can investigate. From the files on its drives, I can see there were older versions, and they were used by the client for a few months. I also see that the newest version is not installed yet on this machine. So, I tried running the old versions first, to see what's the problem.
What user sees:
oldest versions (say, v1, v2) of the application does not work at all. When they start up, the only thing the application displays is ... absolutely completely black window. There should be a "welcome" screen, composed of few images and labels and a button. The app is not frozen it is "responsive" (Win7 can communicate with it, the window is not dimmed).
last (but not newest, let's name it v3) application runs fine, everything is clickable, features work OK, except one. When user is asked to provide a password, the user is presented with single TextBox in a popup. When the user enters at least one character in that textbox, the application freezes. It freezes even before having rendered the masked '*' of the password. The freezing is total, the application stops responding (the window is dimmed and the OS wants to close it), CPU goes to 100% (actually 50%, two-core system) and the only way to stop is kill it via task manager.
then I installed and tried running the newest version (v4) - it behaves just like v3 above
I've also tried reinstalling all the versions, just to be ensure the .EXE/.DLL files are not damaged - no changes (v1/2 - black, v3/4 - freeze on text)
Technical bits, just FYI:
The app is very simple, one executable with no shared libraries and no shared configuration. There is just no way the newest version could interact with old versions. Seriously, I intentionally made the app in a way it can be "just copied" and several instances can be safely kept in separate folders.
All versions of the app (v4, v3, v2, v1) work properly on all other machines, with various versions of Windows
The problem can't be related to user files or configuration, I tried copying them from problematic machine to healthy ones, and the problem does not repeat
Related to password box: There are absolutely no event handlers in the code that could produce a deadlock or freezing. The password textbox has no text-changed handlers. My code reads the text only after an "OK" button is pressed. The app freezes immediatelly when user enters first character, the
user does not even get a chance to press "OK"
Related to startup: The app does almost nothing on startup. It merely displays some form of a splash/welcome screen. There is no logic there except for a nice UI and one button. The user has no chance of pressing that button. When the app starts, the screen is black and has no contents, not even the splash/welcome image.
Tracing and observations:
I've focused on the TextBox part, since it's more granular.
I've got the app to freeze again, and checked the threads with ProcessHacker.
Except for typical threads, one thread that was sitting and busy-spinning at:
wpfgfx_v0300.dll MilGlyphRun SetGeometryAtRenderTime
wpfgfx_v0300.dll MilGlyphRun SetGeometryAtRenderTime
...
wpfgfx_v0300.dll MilContent DetachFromHWND
That's certainly problem with the WPF layer itself. The DetachFromHWND tells me close to nothing, but MilGlyphRun is surely about the text rendering. It freezes while trying to render the text. I've checked the black-screens on older versions of the applications, but I couldn't catch it, since the apps were not frozen, just black.
So..
I've applied literally all pending updates (like, 150 of them, ~800 Mb, most of them were to the OS and .Net framework)
I've tried reinstalling all video drivers
No changes, still black screen, still freezing.
So, focusing back to the problem. It failed to render a text. Sounds obvious, since it deadlocked when user entered a character into a textbox, but it's damn not obvious! The user was presented with tons of different TextBoxes until he finally got to the PasswordBox. All TextBoxes worked OK, only this one fails. And why old verions of the app display black screen and the new version displays the "welcome" screen properly? How can be those issues related?
The connection is: Windows Presentation Foundation Font Cache service.
Sources:
http://support.microsoft.com/kb/937135
http://social.msdn.microsoft.com/Forums/vstudio/en-US/7cc032c1-5f4d-4518-adc6-f53afd051e6b/presentationhostexe-running-at-50-cpu?forum=wpf
WPF uses a Font-Cache service, running as a separate process, for, well, caching fonts. Whenever your WPF app needs to draw some text, it might ask the cache service for fonts. Once in a while the font cache might get corrupted and it then will/may randomly impact any WPF application.
Unfortunatelly, restarting the service is not enough. When this happens, you must delete all FontCache files that this service keeps on the disk. Before deleting them, you must stop the "Windows Presentation Foundation Font Cache service (or whatever it's called in your languge, for example Usługa buforowania czcionek platformy Windows Presentation Foundation in Polish..). Then, go to
Win7: %systemdrive%\Windows\ServiceProfiles\LocalService\AppData\Local\
Vista: %systemdrive%\Windows\ServiceProfiles\LocalService\AppData\Local\
WinXP: %systemdrive%\Documents and Settings\LocalService\Local Settings\Application Data
and remove all files looking like FontCache.dat. The source articles mentioned only one file (FontCache3.0.0.0.dat, but in my case there were around 8 files with similar naming convention).
After deleing them and restarting the service, all versions of my application were running properly again. No black screens, no freezing on textbox.
This scenario has come up before and I'm wondering if there is any way I can determine where the actively running form is executing within code? The problem is when I inherit a very large application which I'm not totally familiar with yet and I have it running through VS.NET 2010. I might have a particular screen up and go "geeze it would be nice if I could start debugging when I do 'x'".
If this was a simple form with some buttons I wouldn't even bother asking here; I'm not that novice. But the time consuming task is when I look at a tabbed screen in a large multi-project solution with drag and drop capabilities, right click options, etc. and have to spend 5-10 minutes tracking down where to place a breakpoint to debug.
What I'm wondering is if there is a way to have the WinForms app running via IDE and do 'something' that tells VS.NET on the next action break into the code (obviously without a breakpoint because I don't know where to place one yet). This would save me a ton of time trying to track down which event is occurring in a not so simple form or series of forms.
I hope this makes sense...
Thanks!
Yes, that's somewhat possible. When you use Debug + Break All then the 99.9% odds are that you don't break into code that's part of the project. A Winforms app is normally idle, pumping the message loop and waiting for Windows to tell it that something happened. You'll break at the Application.Run() statement.
The trick to then use Debug + Step Over. The program resumes running like normal. Then give a UI command (do 'x' in your question) and the debugger will break at the first statement of real code, typically at the start of the event handler for that command. It isn't exactly guaranteed that that code would be relevant, you might break at a MouseMove event handler for example. So YMMV.
I just discovered this problem today, and I had no idea what caused this problem. My project had been developed for few months.
I have a project(solution), with several projects in there, it works well if I write and debug, by pressing F5.
The problem occur is when I press Ctrl+F5 (to skip debug mode), or run directly from double click the exe, it crashed. The errors dialogs that pop up every times are different, but OutOfMemoryException is the most frequent one.
I had checked to make sure all my projects are .Net 3.5
I put a MessageBox.Show("something") at the beginning of my main project constructor, but it never reach.
I use some registry cleaner to clean/fix my registry, scan for viruses.
I had try to read the meaning of each error and exception, but still no clue why it happen.
These are a series of screenshots if I press Ctrl + F5. (FutureGenerator is some random name I gave to my project.)
Series of screenshot if I run the app from my debug folder, FutureGenerator.exe
I suspect this is caused by framework crashed during Windows Update, but I removed those update that I performed recently, still same. The exe file works on other non development PC, but I don't want to reformat my PC or reinstall my VS, yet, because it's a painful process.
Any idea, anyone?? Million thanks.
You mention v3.5 but the very first screenshot is about v4.
Try repairing your Framework 4 and/or VS2010
I found the problem. It's actually because I added FutureGenerator.exe into Application Verifier by Microsoft. The verifier only support debugging testing.
After I removed FutureGenerator.exe from the Application Verifier, everything's ok.