I have installed cc.net 1.4.3 version on Windows Vista. But It keeps giving me Interactive services dialog detection when I execute tests. I even have disabled the interactive services from services panel. but still getting this.
Any idea how to get rid of this problem
regards
Sam
No easy fix that you can do. The service is trying to pop up UI on the user desktop. In XP this worked because services and the first user log on both run in session 0. In Vista, services run in session 0 and the first user runs in session 1, so there is no way for a service to directly show UI to the user. This was due to security issues - search for Win32 Shatter Attack to get more details, but basically an untrusted user could send malformed window messages to the services, and in some cases could even cause arbitrary code execution.
You can disable it altogether by disabling the "Interactive Services Detection" service on the system. But you won't see notifications at all, and this will disable it for all interactive services. Best approach is to complain to the vendor to update their software for Vista.
EDIT: And the software is broken on XP when multiple users are logged on and the active user isn't in session 0.
Related
We have a windows service that gets installed and runs on users system in the background, but on some windows machine user get an error "A device or program has requested your attention" This is specific to Windows 7.
This is because when we are installing the .exe on the user machine using MSI(created with WIX), the installer job I believe runs on Session 0, and when any prompt appears the user is prompted that a program has requested attention and he gets switched to Session 0. Can we suppress messages for installer or exe running in Session 0.
Thanks.
To fix this you will have to determine what UI is shown if the user switches to Session 0, what shows it, and how to remove it.
Services run on Session 0. Before Windows Vista, they could interact with the desktop, so many did. Chances are your service is trying to show some UI. Upon detecting this, Windows is trying to help you out. Fix the service to avoid showing UI, and the message will go away.
It's plausible that this could also occur for a deferred custom action in the system context (as those are invoked by the Windows Installer service), but I've never run into this scenario. If so, the fix is the same: make that action not show any UI.
Michael's correct, but I want to expand on it a little.
The issue isn't primarily about session 0 or services. It is about anything that tries to show a UI that is not part of the interactive user's current session. The main problem is the shatter attack where (for example) something running with the system (or otherwise privileged) account shows UI to the (perhaps limited) interactive user. The window into the privileged process is a security hole. As a result, attempts by an install to run custom actions with the system account (deferred CAs) that show UI are an issue, as are services. Session 0 is really just part of the implementation that is intended to address the security issues.
So yes, address UI attempts from your services and from (primarily deferred) custom actions in the install.
Is there a way to find out what privileges my application needs in order to run in a Windows 7 environment?
I have a Delphi application that is using BDE and ODBC for database connectivity. This application works on most computers with Windows 7 running on a normal user account. However on some computers it only works on accounts with administrative privileges and is not working correctly on normal user accounts. I suspect it's a permission problem. The computers also are running in Active Directory.
I tried to find some informations using Process Monitor from SysInternals, however the output for me is too advanced. The process monitor log for two runs of my app (1. successful with administrative rights, 2. unsuccessfull on normal rights) had over 22k lines and i could not find the answer (needle) in the process monitor log (haystack).
What could i do to determine the privileges that my app needs in windows 7?
Use the Standard User Analyzer from the Microsoft Application Compatibility Toolkit.
The Standard User Analyzer (SUA) tool and the Standard User Analyzer
Wizard (SUA Wizard) both enable you to test your applications and to
monitor API calls in order to detect potential compatibility issues
due to the User Account Control (UAC) feature in the Windows® 7
operating system.
UAC, formerly known as Limited User Account (LUA), requires that all
users (including members of the Administrator group) run as Standard
Users, until the application is deliberately elevated, by using the
security prompt dialog box. However, not all applications can run
properly with the Standard User role, due to the application requiring
access and privileges for locations that are unavailable to a Standard
User.
Aaron Margosis has a tool called LUA Buglight that is designed to help track down issues related to privileges.
You can download the latest version from this blog post:
LUA Buglight 2.1.1 with support for Win7/2008R2 SP1
It is similar in concept to the MS Application Verifier. However, in practice I found LUA Buglight much easier to use and understand. Same with ProcessMonitor. It will monitor your process in a similar way but only report actions that failed as a normal user but succeeded as a admin user.
There is no documentation but it is simple to use. From the main GUI window select your Exe and let the BugLight program launch it. You need to be running in an Admin account with UAC enabled. Run your program though the steps that fail when you are not an admin. When you are done click on the Stop Logging button to see a report that lists what calls would have failed without admin rights.
I'm writing a server running as a Windows service that by request invokes Firefox to generate a pdf snapshot of a webpage.
I know it is a bad idea to run a GUI program in service mode, but the server nature of my program restricts from running it in the user mode. Running a user-level 'proxy' also is not an option, since there might be no interactive user logged-in on the machine with the server running.
In my experiments Firefox successfully produced pdf when the service was running under a user account that was already logged-in. Obviously it didn't work in other cases: for Local System and user accounts that weren't logged-in. Under LocalSystem with 'Allow service to interact with desktop' option enabled I could see the Firefox started that reports that it's unable to find a printer.
Since it wouldn't be practical to require an opened user session for the pdf server to run, is there any workaround for this except running the whole thing from a virtual machine?
UPDATE: I figured that the problem wasn't really with account permissions, but with an invisible modal dialog that FF was waiting on while running in the service mode.
However it's still unable to create a pdf when FF is running under the LocalSystem account. FF says it can't find a printer and I'm wondering if this is a permission that could be somehow enabled?
You might want to try a different approach where you'd include some .NET PDF library (PDFsharp is a good, open source, choice) in your project and than use that in conjuction with WebBrowser control you'd also include in your project to render the PDF.
Don't forget to use STAThread attribute if you try this.
I've been through a similar conundrum with the MS Word running unattended. What you need to do is to login as the user you set up to be used to run firefox process and go through the process of setting up printers.
It is possible that just logging in as that user will be enough - there is some stuff performed during the first logon.
I apologize I was not clear enough - I mean you have to logon interactively using that account, configure the default printer, logout, and then run your service
Can you run the program as a Scheduled Task instead? The task can be assigned to a given user account which should work around the service limitations.
A couple of year ago I had a related issue: Shared Network Printer on pseudo-device starting up Ghostscript for PS->PCL translation and printing to real printer. The print-spooler service ran as Local System and the pseudo-device driver hat troubles executing Ghostscript from the service-mode. I was able to solve the problem by copying a couple of registry keys from the HKCU-hive to HKLM.
#UPDATE:
OK FOR ANYONE ELSE WHO IS SEEKING ADVICE ON THIS ISSUE...
So far, the best thing I have found is to download yourself a copy of pGina and for 2k/XP modify the GINA, and for vista/win7 you will need to create custom login credentials (pGina have the tools/samples to interface with the Vista/Win7 architecture).
to confirm -- it appears that this is what Novell are doing with Vista/Win7 rather than the traditional method of replacing the GINA (like in 2k/XP)
If anyone else comes up with a way to run an application on the logon screen in Win7 please post it.
Ok I'm writing some vb6 software that requires input before the user logs on to the system.
Basically I want to run an application on the Windows logon screen where the user can interact with the program. At present I have the application running as a service allowing to interact with the desktop, but it is still now showing.
I know that "Allow service to interact with desktop" will work in Windows 2000 / XP, I'm running Windows 7 - I am also aware that services cannot directly interact with a user as of Windows Vista - saying this, are there any other methods to get my application running on the logon screen. Novell does it
Does anyone have any other ideas to get this working?
You can only do this if you are authenticating the credentials yourself. Prior to Vista, this was done via GINA, but since Vista, you need to write your own Credential Provider.
The reasons behind this are buried deep in the security principles -- Ctrl-Alt-Del will only ever bring up the window station associated with login (etc), and no other application can get to that window station (so you can't create a fake password box over the top to scrape passwords, for instance).
Without knowing why you think your service needs to interact with that desktop, it's difficult to advise further, but it might mean that your design is broken somehow.
Service isolation will probably prevent you doing this from a service.
Pre-vista Novell and the like would probably have used GINA, which was replaced in vista; http://msdn.microsoft.com/en-gb/magazine/cc163489.aspx
The only way I know of would be to write your own msgina.dll.
It can get dicey during testing though. Any mistakes can mess up your OS so bad that a complete reinstall becomes necessary.
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.