My app is a document-based Xamarin.mac app that uses WKWebView to display HTML content generated in-code. Each time a new window is created, 2 new processes are also created: 'APP_NAME Networking' and 'about:'. However, when the window is closed, the two processes remain. Open 10 windows, close 10 windows, and I have 20 orphaned processes.
Does anyone have any ideas for how to make these go away when the window is closed?
(EDIT)
Please note that these are not orphaned objects/data structures, but independently running system processes that are owned by the app, but not by the document window/view controller that spawned them. Quit the app, the child processes die. But close the window, and the child processes live on...
Memory management in .NET is based on the garbage collection. As such it is indeterminate from the point of app or developer. Meaning that things like above are not unexpected in .NET.
In Xamarin there is the additional problem - Xamarin is keeping reference on native resources, but it has no idea what those resources are and how much computer resources they take, so the automatic garbage collection is frequently not happening when you expect it.
It is suggested that you should Dispose the important native resources that you don't need. I would definitely consider WKWebView among such resources.
Other than that you may also initiate garbage collection manually, but that is not recommended unless really needed.
Related
On Windows, what are all the possible creation entry points for user objects? I have been trying to isolate a handle leak in a .NET application for quite some time now. Here is what baffles me:
• Leak only occurs in window management objects (aka. USER objects - not kernel, not GDI).
• Leak only occurs when the application has focus. Clicking on another application "pause" the leak until we click on the application window again.
• Leak occurs even if process is suspended (through task manager or debugger).
I've been trying to intercept any and all object creation methods, but my Visual Studio debugger remains suspiciously silent. I do get the occasionnal call to some user32.dll methods (as described in https://learn.microsoft.com/en-us/windows/desktop/sysinfo/user-objects), but nothing that would account for the leak or come close to the system limit of 10 000 objects.
Any suggestion? Does anyone knows if some hidden system thread remains active even when my application is suspended? Thank you.
Ok, our team has been able to find one probable cause for the issue. Turns out that Microsoft's documentation tells only half the story. If at some point user and kernel objects were completely separate, recent versions of Windows have blurred the line.
As such, DDE transaction, monitor, keyboard layout, keyboard file, event hook, timer, input context, device info, touch data, gesture data and HID data should all be added to Microsoft's list of user objects. Some kernel methods may rely on user objects to provide services to apps.
To be specific, calls to RegisterRawInputDevices will result in the application receiving WM_INPUT messages. Those messages are backed by HID data and must be processed in a timely manner. If the process is suspended, unresponsive or otherwise fails to process incoming messages, there will be an accumulation and an exhaustion of system resources. This can quickly escalate into the problem described above and lead to an application crash.
I have a windows 8 store app and a Background task is also associated with it. Everything working fine. And my question is, is there any possibility to close my app from BackgroundTask Run method ?
thanks for suggestions.
No, You can't do that instantly!
But you could save a file in your app's local storage -or settings- and let the foreground app check for this file every 10 minutes -whatever- and close the app in a specific condition ..
Your background task can be hosted in its own dedicated process or it can be hosted in the same process as your UI. In a separate process your foreground app can open and close without impacting your background process. In the shared process when your foreground app closes, so does the background task. This is not true in reverse, the shared process model does not allow a closing background task to close the foreground app. Too bad, huh?
Technically, it is not recommend that a foreground application close itself. But, hey, that API is there for something, right? When the background task shares the process with the foreground app then it can communicate directly between them with shared memory. This would introduce method 1 for communicating from your background task to your foreground app - probably by using a static event.
If that's not what you want, and you need separate processes, then your options are a bit more tricky.
Here's the best option:
You set a special setting (let's say it's ApplicationData.LocalSettings.Values["DataFromBackground"] = "PleaseExit") and then call the ApplicationData.SignalDataChanged method from the background task which will raise the ApplicationData.DataChanged event handled by the foreground app. How much lag will there be? I am not sure, but there will be some, so be ready for that.
Be sure an remember to set DataFromBackground back to some empty value, including calling Value.Remove() so you don't mistakenly process it again. That being said, you should also poll for that value when your application launches (or resumes) in case your background task wrote it while the event could not be heard.
This is probably the easiest way to implement communication.
Make sense? I speak more on this in my Ignite session on the topic.
Best of luck!
I'm writing WPF application
application targets all sort of windows and low performance computers
so I want to write launcher/splash screen for it which will be displayed before application loads
I'm not sure what language to use or what technology
I want it to be very fast and lightweight
can you suggest anything ?
Displaying a flash screen is as easy as popping up a dialog. If the dialog has the various resources such as bit maps already included then it is quite fast. However one issue that will determine this speed is how much other stuff is being initialized at application startup before the code is hit to display the dialog.
So one option would be to have a very simple application that does nothing more than display the flash screen and then start up the actual application. A simple Windows dialog application would do that. You would need to figure out how to synchronize the actual application finishing its initialization and the launching application stopping if you choose this route. There are several techniques for this and the most likely would be to use an interprocess mutex or perhaps just look for a file to be created.
For a point of sale I work with that is launched as part of turning on the terminal we ran into problems in which the application would start before some required system services such as database manager were up and running.
We have found that some environments require much more time than others so a registry variable makes it easy to tweak the delay in the field.
So as part of the application initialization what we did was that when the application starts up, it displays a dialog with a progress bar. The progress bar does a count up and we have a loop that does a one second sleep then increments the progress bar.
The number of seconds to wait is a registry setting for the application with a default value.
One problem we ran into was that when doing development and testing in a debugger, the default value was way too long for impatient programmers wanting to get started so we have condition compile so that if it is a debug compile, the delay is set to a couple of seconds. Otherwise the default is 10 seconds. However it can be changed with a change in the registry value.
See also this Stackoverflow about a launcher.
If you want something realy fast and lightweight, C would be nice.
If you dont want to learn C, you can also make a console application with .NET and C# it's fast too
Edit for comment: You can use a library like SDL wich is very fast and powerfull, and can draw images from a console application.
In Visual Studio's Attach to Process dialog, one of the columns in the Available Processes list is "Title", which lists the title of the topmost window owned by each process.
We spawn multiple instances of several server processes in order to compartmentalize the work. For these console processes, the Title field is blank, so currently we have to look up the process id in our management tool in order to find the correct process.
In order to streamline the debugging process, I would love to be able to use the Title field to directly determine which process I want.
SetConsoleTitle does not do the trick, nor SetWindowText with a NULL hWnd. To the best of my knowledge, a console application does not intrinsically own any window handles that we could pass to SetWindowText. We don't want to create any visible windows for these server processes.
Any suggestions for a reasonable way to trick Visual Studio into displaying some useful information here?
I think you might be out of luck. The console window does not belong to the console process, but instead belongs to a system process (conhost.exe on win7 and maybe vista, csrss.exe before that) so if Visual Studio is just looking for a processes top level windows it won't find the console window. Probing consoles out of proc is not supported as far as I know, so there is probably no sensible way for visual studio to see the title of the console windows you have.
One possible solution might be to create a top level window in your console process as a debugging aid. You might want to conditionally compile it, so it is only available when you're debugging though. Just create an additional thread which pumps messages, and create a top level window. If you set the right styles the window will be invisible. You might not want to ship with the window in the code because in long running server code, windows always increase your attack surface, even if only a little bit.
This is probably not very helpful, but it is worth mentioning that on windows the preferred way of portioning up work would be to use threads rather than multiple processes. A process is an expensive object, and threads are much cheaper in terms of system resources as well as being easier to debug.
I am debugging an application which, in its message loop, calls IsDialogMessage(). Occasionally, IsDialogMessage() never returns (where never is an interval greater than 1 hour). Based on the symbols for user32.dll available from Microsoft's symbol server, it appears to be stuck in GetNextDlgGroupItem() (or an internal variant of the same), iterating over some set of windows.
The application is multithreaded and frequently receives notification of external events, which arrive as DCOM calls. I suspect that such a call is handled incorrectly in a way that corrupts some window state. If I can learn what sort of state corruption might cause an infinite loop in IsDialogMessage(), I think I will be more easily able to identify the source of the corruption.
I know this is old, but answering for posterity since no one here mentioned it.
More than likely what is going on is trouble with the windows manager determining where to forward a message. If you have a hierarchy of windows, as you probably do, then you need to ensure that non-top-level windows that contain controls themselves must have the WS_EX_CONTROLPARENT style set. If it is a dialog, you use the DS_CONTROL style. The presence of these flags modify the behavior of IsDialogMessage; they identify a window as having its own controls which can receive focus and handle tab order, etc, rather than just being a control itself.
For example, if you have a main frame window, which has a child window with WS_EX_CONTROLPARENT, which has a child window without WS_EX_CONTROLPARENT, which has a child window that has focus, and you hit TAB, you will likely encounter an infinite loop at the same place you mention.
Setting the second child's extended style to include WS_EX_CONTROLPARENT will resolve the issue.
Are you maybe disabling controls (using ::EnableWindow()) without checking first whether that control has the focus? If yes, then the focus gets lost and GetNextDlgGroupItem() gets confused.
Another reason this can happen is if you reparent a modeless dialog. At least this can happen with wxWidgets...
I've made some investigation, trying to answer this question. But only in situation, when parent window is in native MFC project and child is a managed C# Windows Forms. If you have such situation, then you may try 3 resolutions:
Run MFC dialog message loop on Windows Forms side. Here is more info: Integrate Windows Forms Into Your MFC Applications Through C++ Interop
Create 2 threads: one for Windows Forms dialog and one for native dialog. Here you can create dialog in Windows Forms, then with SetParent() set it's parent to native dialog. But be ware: if you add TabControl to Windows Forms, than hang with "IsDialogMessage() never return" will occur.
Make a wrapper for Windows Forms dialog to use in native project. For ex., wrapper may be WPF, see here: Windows Form as child window of an unmanaged app
I've taken information mostly from: http://msdn.microsoft.com/en-us/library/ms229600.aspx
And the temporary cure can be to change focus behavior. For example, disable them, or SetFocus() to parent or child windows only. But I strongly recommend to investigate the real reason, why IsDialogMessage() never return in your case.