Is there an easy way to tell Windows not to display popups on a headless server machine?
Currently occasional application popups are causing my app to freeze because no one is available to press 'Okay' on the console. Just logging to the eventlog would be more than sufficient.
Depending on precisely what popups need to be handled, there are a couple of approaches.
For hard error popup handling, HOWTO: How To Change Hard Error Popup Handling in Windows NT
Creating an application to suppress messages. Microsoft has some documentation (from the XP Embedded documentation, but this does not require XP Embedded): Creating a Win32 Service This allows for considerable customization in the handling of the messages, logging, and replies (i.e. depressing the button you want).
It all depends on the kind of popup, from system's message box to custom dialog. So I don't think there is a generic solution to this.
Should I have the problem, I would use a macro language, like AutoHotkey (or AutoIt), to detect the activation of the popup and automate the click on the discard button.
[EDIT] Found a ready to use AHK popup blocker: New window (popup) blocker
Perhaps usable as is, or as a starting point.
Related
My global problem is to switch off all the...
notifications
popups by Windows
system hard errors dialogs
...while some application is running.
Switching off Notificatins and Errors dialogs via Registry was an easy task - thanks for Google and MSDN.
And working with popups (as on the picture - link below) is a hard task. I couldn't find any detailed description about their behaviour and how to control them.
Does anybody know how to switch off all the similar popups (not only regarding updates)?
And which types of these popups are there in Windows? I saw about Restaring, Updates ready, Low Battery...but I suppose that there are more.
And the last: how to emulate these popups for testing purposes?
Example of popup:
Set all values to 0 for the following registry -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings
RegEdit
I did some googling on this and only found this link Stack Overflow Link which discusses what causes the Socket Notification Sink error.
The application environment is currently Win2003/VS6.0/MFC/C++ we are migrating to Win2012/VS2013/C++/?MFC? (I use question marks as I am not directly involved in the GUI implementation and don't know the roadmap).
In my case I work with one or more applications that for some reason have crashed. This will generate from 1 to 300 "Socket Notification Sink" dialog boxes that must be individually dismissed before recovery can begin.
I am looking for some recommendations:
Methods to clean up on crash to prevent the dialog from occurring.
Methods to instruct the Windows runtime to not generate a dialog box on
error. Redirect errors to a log or error console.
Method to dismiss all the error dialogs with one mouse click/Keystroke
I think this is what you're looking for:
Windows has a registry setting called error mode that controls how the system presents errors to the user. You can use it to have the system skip popping up the dialog box and instead write the information to the event log.
See my answer to this question.
You can also set ErrorMode for your program in code using the SetErrorMode API.
This affects only your program.
I have one windows form UI wizard as custom action in MSI setup project in Visual Studio 2013. During installation one small progress bar dialog appears on top of the UI. This dialog also has a Cancel button and text like 'Please wait while Windows configures....'
Can we hide or disable this dialog somehow? Can we disable the Cancel button on this dialog? Or can we take this dialog behind the main UI so that user will not be able to click Cancel? Or Can we detect this Cancel button click event and handle in custom action?
There's no good answer to this, so basically this is just information.
The Windows Installer architecture expects all UI to be done in the first UI sequence, that's where data is entered. You probably understand this from the vast majority of other setups that do this. The execute sequence is intended to be silent except for errors and a progress bar. When Visual Studio setups allowed installer classes as a way for people to run managed code custom actions I don't think they expexcted people to have UI there. It often doesn't work because of the STA/MTA thread differences for message pumps, and since Windows Installer itself knows nothing about your custom action showing UI (there's not supposed to be UI!) it still believes it has the user's focus. The other issue is that many customers expect to be able to do silent installs, your requirement for a UI wizard defeats this.
I think some people have tried to solve your problem by enumerating all the Windows on the system to find the Windows Installer one and forcing it to the background, but I haven't seen anything recently on this or any code examples.
In your case, if your UI data can be collected up front with one of the canned UI dialogs then try that. Unfortunately VS setups don't give you a way to validate the input. If the UI wizard is for the app itself then it's usually easier to do it when the app first runs, as well as being easier to test and debug, being able to run later to reconfigure, and avoiding this kind of issue.
The limitations of VS setups include not being to design your custom dialogs to collect and validate input in the expected way at the beginning UI sequence. Also you cannot disable the Cancel button because VS custom actions run after everything is installed, which is too late to send the message saying "disable the cancel button". The overall issue is that you're fighting the limitations of VS setups, and another tool might be a better way to go, or have that UI wizard run at first boot of the app.
I am able to hide the progress bar dialog itself using Win32 APIs.
On Microsoft Windows (8), I would like to start a process, and prevent it from showing any windows at all. Alternatively, to force-close any windows that are shown. Is there a way to do this?
My application is this: I'm running an automated (nunit) test suite on my continuous integration (teamcity) server. The code under test is also used by an interactive application. Developers occasionally slip in a dialog with a user prompt, without realising what they are doing. This causes the CI process to stop, waiting for user input which never comes. I'd like to be able to dismiss any dialog that appears, or prevent them from being shown.
Even better would be to force an exception at this point, so that the test would also fail.
In my case, this is a C# application, and the dialogs shown are Windows Forms or WPF dialogs.
I did find a couple of similar questions. However each turned out to be solving a slightly different problem.
Stop a process from showing a window from C# (solves a different problem)
Preventing blocking dialogs/message boxes/hanging GUI from non-interactive processes on Windows? (promising solution but C++-specific)
Prevent child process from creating visible windows? (solves a different problem)
Have you considered asking your development team to have a "no dialog" mode of the app for testing purposes? Perhaps if you stopped referring to them as (!!*&%) they would be more inclined to partner with you. ;) Afterall, you do work at the same company on the same product :)
In any case, without a dev-specific solution, consider having a another app (process or thread) that continually sleeps for a few seconds, wakes up and looks for a modal dialog in your application. You can use APIs such as FindWindow to identify when a modal dialog has popped up. (Use Spy++ to get the class name for windows created by MessageBox and CreateDialog APIs).
TL;DR - How does the Spy++ tool really construct its process list?
Stage
We have an MFC desktop application (running on Windows XP) that is hanging in that it doesn't react to any user input anymore. It is redrawn when switching to it via alt-tab however. (It does receive WM_SETFOCUS, WM_ACTIVATE, etc. It apparently does not receive any mouse or keyboard messages.)
Since the app is hanging in some limbo, we pulled a few process dumps, but these were of little help so far. Enter:
Spy++
We used Spy++ to find the information I gave above about the window messages this application seems to be processing. We did this by Opening the Windows View and selecting our application Window and in the Messages properties selected Windows of same process and Messages to View : Select All.
However we first tried to view all messages of this process by opening the Processes View of Spy++ and our application is not shown in this process list. Cross checking on another PC where the app is running normally, the process is also normally shown in the processes list of Spy++.
Can anything about the misbehaving app be inferred from the fact that the process is not shown in Spy++'s Process View, but the main window of the app is shown in the Windows View. Why would a process with a main window that is visible not be shown in Spy++'s Processes View?
The process is listed in Task Manager and in the Attach Process Window of Visual Studio 2005. So these tools apparently use a different method to list processes than Spy++ ... ?
The system where the app is currently hanging is a Windows XP SP2 system and we've used the Spy++ Utility that comes with Visual Studio 2005.
The behavior does recur occasionally, but only after the App has been running for several days!
Running Vista or later? Your process is probably elevated and Spy++ is not. Newer versions of Spy++ require elevation. So, try elevating Spy++ explicitly and see if that helps.
Yes, of course things can be inferred from this. Don't take anything I say too seriously in this context, I'd have to go look at the code. But I believe that Spy goes off and looks at the EnumProcesses API. (http://msdn.microsoft.com/en-us/library/ms682629.aspx)
So, if your process isn't showing up there... hrm.
But, what is different between the system where it's working and the one where it's not?
Spy++ requires the following two values in the registry to be disabled (0) to display the processes/threads list AT ALL:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
HKLM\System\CurrentControlSet\Services\PerfProc\Performance
Disable Performance Counters -> either 0 or not present
Was going insane trying to find out why it refused to display them. It's some kind of bad joke - this debugger requires itself a debugger to get it working! Not that WinDBG would display any meaningful info, MS doesn't even provide a symbol file on their symbol server, pfft.
Anyway, maybe it doesn't display processes that have their performance counters disabled, because I think, this can be set on individual basis, at least for services, like:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
Disable Performance Counters
So it's basically always a value of the "Performance" subkey. All this stuff is undocumented, it makes use of advapi32.dll functions like "PerfRegQueryValue" and "PerfRegQueryInfoKey"... don't ask me.