i have a WPF application that sits on top of all other windows. 99% of the time it works perfectly however if i dial into my computer from another location using remote desktop and then close the connection and go back to the original computer, my application is not visible. checking the running processes i can see that it is still running however its not visible at all. I assume it has something to do with the remoting but i was wondering if there is some code i can run say every 20 seconds that sits on its own thread that checks whether it is visible and if not will execute some code whether by pInvoke or .NET to become visible again. Any ideas?
Make sure to upgrade to .NET 3.5sp1. There were some changes with remoting which lead to WPF applications being sent as bitmaps in remote desktop in all situations.
In earlier versions of the framework, there were problems with WPF applications causing very odd behavior when combined with remote desktop.
Another idea - make sure you're using the latest and greatest versions of your graphics drivers from your graphics card vendor. WPF makes heavy use of DirectX, and this could potentially be a driver bug preventing the context from resetting appropriately.
Related
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.
I grabbed this multi window test code, changed it to use D3DXCreateTeapot instead of D3DXLoadMeshFromX (I couldn't find a teapot.x file), moved the EndScene call below the DrawText call and set NUM_WINDOWS to 1. With those minor changes, the test works and creates two windows, each with its teapot.
I built the test and deployed it in a machine which has an Intel HD Graphics onboard GPU with two heads, each attached to a monitor. Then I moved one window to each monitor, and enlarged both windows to take up about 80% of each monitor space.
With this setup, which is quite close to what my app needs, the window in the secondary monitor always goes too slow. If I swap the windows, it's the same: the one in the secondary monitor starts crawling, and slows down the whole system.
I googled around and some sources (albeit dated) state that only the primary monitor can use hardware acceleration when not in fullscreen mode. I cannot use fullscreen because direct3d9 rendering in my app is done inside a user control embedded in a Winforms GUI.
Is it really impossible to get hardware acceleration for both monitors in windowed mode? The legacy version of our application uses MFC + DirectDraw and manages to perform fast enough, but those are obsolete technologies and we'd abhor going back there.
You have 3 options:
Try many combinations, like: D3DPRESENT_INTERVAL_IMMEDIATE +
(D3DSWAPEFFECT_FLIP or D3DSWAPEFFECT_COPY) +
D3DCREATE_ADAPTERGROUP_DEVICE. Maybe some will offer better
performance.
Render to a surface, convert to a bitmap, and use it like any other bitmap in your form. Something like this
D3DXSaveSurfaceToFileInMemory.
Change your code to DirectX11. You have more options for GDI interaction there. Better rendering behavior. Maybe better drivers.
Some years ago, I made some multiple window code, also multiple device, using DirectX10/11. I can't tell about DirectX9 having this issue, seems absurd to me, but could be your Windows version, or Intel driver.
Here is the situation. The company I work for builds this piece of software in c that can make a Windows computer act a bit like a TV. Essentially, our piece of software is meant to be played full screen and content is displayed from the internet without the user having to ever touch the computer again.
The problem is that once in a while, the system brings up pop-ups like "Your Windows system is ready for an upgrade." or "Please renew your Norton subscription" etc. which the user has to periodically and manually remove.
Is there a way to display content full screen without being bothered by those warnings?
Yah, whether or not the development community agrees, Microsoft has several standards for when and why it might be acceptable to have exclusive use of the monitor.
The most official strategy is to use DirectX in exclusive mode. This is what games do, what windows media player does in full screen video with hardware acceleration enabled, etc... If your application is multimedia intensive (as suggested by TV like functionality), you should probably be using DirectX too. Besides giving you the exclusive display access it will also increase your applications performance while lowering the CPU load (as it will overload graphics work to the video card when possible).
If DirectX is not an option, there are a great number of hacks available that seem to all behave differently between various generations of windows operating systems. So you might have to be prepared to implement several techniques to cover each OS you plan to support.
One technique is to set your application as the currently running screensaver. A screensaver if really just an EXE renamed to SCR with certain command line switches it should support. But you can write your own application to be such a screensaver and a little launcher stub that sets it as the screensaver and launches it. Upon exit the application should return the original screensaver settings (perhaps the launcher waits for the process to exit so that it returns the settings in both graceful exits and any unplanned process terminations ie: app crash). I'm not sure if this behavior is consistent across platforms though, you'll have to test it.
Preventing other applications from creating window handles is truly a hack in my opinion and pretty bad one that I wouldn't appreciate as a customer of such software.
A constant BringWindowToTop() call to keep you in front is better (it doesn't break other software) but still a little hack-ish.
Catch window creation messages with a global hook. This way you can close or hide unwanted windows before they become visible.
EDIT: If you definitely want to avoid hooks, then you can call a function periodically, which puts your window to the top of the z-stack.
You could disable system updates http://support.microsoft.com/kb/901037 and remove the norton malware.
You could also connect a second screen so that the bubbles appear in the the first monitor.
Or you rewrite it for linux or windows ce.
One final option is to install software that reconfigures your os into a kiosk http://shop.inteset.com/Products/9-securelockdown.aspx
If you don't need keyboard or mouse input, how about running your application as a screensaver?
A lot of thoses messages are trigged/managed by Windows Explorer.
Just replace it with your dummy c#/winform.
By changing the registry value
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="Explorer.exe"
You can specify virtually any exe as an alternative to explorer.exe
That's the way all windows based (embedded) system (ATM & co) do.
There's still few adjustment (disable services you dont need / dr watson & others), and of course, you'll want to keep a "restart explorer.exe" backdoor.
But that's a good start
I am testing my application (Windows 7, WinForms, Infragistics controls, C#, .Net 3.5).
I have two monitors and my application saves and restores forms' position on the first or second monitors. So I physically switched off second monitor and disabled it at Screen Resolution on the windows display settings form. I need to know it is possible for my application to restore windows positions (for those windows that were saved on the second monitor) to the first one.
I switched off second monitor and press Detect to apply hardware changes.
Then Windows switched OFF the first monitor for a few seconds to apply new settings. When the first monitor screen came back, my application became unresponsive. My application was launched in debug mode, so I tried to navigate via stack and threads (Visual Studio 2008), paused application, started and did not find any thing that help me to understand why my application is not responsive. Could somebody help my how to detect the source of issue.
Download the Debugging Tools For Windows then run adplus in hang mode. The with the resulting .dmp file open in windbg and invoke:
!analyze -v -hang
You should provide more information about what you saw in the call stack and threads windows. Which threads were running? Did you see anything that was waiting in a sleep or join? Have you tried naming your threads so that it's clearer as to what's going on when you pause (though not necessary since you can get this info from the call stack anyway... it's a convenience thing).
WPF launches certain method which calls external exe and waits , and then accesses a file which was an output of external exe. Assuming I would build this application with a consideration of porting to Silverlight 4 later what should I do ?
In order to do this you would need to go through Silverlight's COM automation. I'm sure there's some out-of-process COM server that you could use to start a process. But at that point you've already
limited your application to Windows
require full trust
will only work in "out of browser" mode
At that point, you really gotta ask whether or not it makes any sense to port to Silverlight. WPF is particularly suitable for the above scenarios. You can use ClickOnce to achieve a similar (actually, superior) client update experience and you won't have to jump through hoops to do something as simple as spawning an external process.