I've been googeling this issue for quite some time now without any success. Basically what i've done is to create a VS2010 Setup Project, the project has a few Custom Actions that interacts with the Spooler Service through p/invokes, adding monitors, ports, printers yada yada.
Ofcourse to be able to do this the spooler service must be running, and also restarted at one point during the installation, however the msi file seems to be able to figure out that I'm working with the Spooler Service and sometimes hints the user/administrator to shutdown the spooler service before the installation starts, this will ofcourse fail the entire installation.
Is it in some way possible to disable these warnings?
Thanks in advance
If you are referring to the files in use dialog, there's not much you can do.
Usually you can avoid this dialog by stopping the process through a custom action, but you need the process running.
Related
In order to build an automated deployment pipeline, I need to be able to clone and deploy Windows Server virtual machines, sysprep them, and then perform various customisation tasks on them.
Some steps, such as sysprep, require a reboot, so I currently simply wait for the reboot to happen, and once the machine comes online again I can execute the customisation on it.
The problem with this is that sysprep performs various actions after the reboot, and as far as I can tell, everything on the machine becomes available during the time when "preparing Windows" is still showing on the machine. This means I can use PowerShell Remoting to start changing things, but I don't want to do my customisations which could reboot the machine, while the first-boot stuff is still happening.
How can I remotely detect that a machine is "fully" booted, or at least past any deployment stages so it's in a state ready to log into? Is there some service that only starts when the login is available? Maybe a registry key to indicate that the boot process was completely fully?
This loop does the trick pretty well for me.
while (-not (Test-Path \\machineName\c$)) {
Start-Sleep 1
Write-Host "Waiting..."
}
From what I've experienced, the file system is accessible a couple seconds after the login screen appears, so I'd assume the system is "fully" booted.
make a loop and wait for following registry key to become IMAGE_STATE_COMPLETE
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\State
IMAGE_STATE_COMPLETE represents fully completed sysprep after reboot.
A legacy Service that I work is freezing due to database issues. And I'm looking for a simpler solution than fixing it.
In Aplication Form Version (Delphi), Windows recognize and show message that application is not responding.
Can Windows recognize when a service is not responding and restart the service?
In Service Properties the Recovery is only for failures.
In Aplication Form Version (Delphi), Windows recognize and show message that application is not responding.
Only if the main UI thread is blocked, but you shouldn't ever do anything in the main UI thread that can block it. Bad code design.
Can Windows recognize when a service is not responding and restart the service?
Not automatically, no. You need to fix your database code so it doesn't freeze up anymore in the first place. If that is not an option (which I highly doubt) then you will have to write a separate watchdog thread/process to monitor your code/service and kill it if it freezes up. If you kill the entire service, then Windows failure actions can be used to restart it.
I keep getting this error:
Error 1061: The service cannot accept control messages at this time
This happens when I attempt to stop the service installed using InstallUtil from this location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe
I am attempting to debug the windows service in question. My problem is that everytime I attempt to introduce changes to the codebase, the computer "A physical machine - Dell Precision T3500" requires that I restart the entire machine to completely uninstall the service, before I do a reinstall.
I have looked at this Link and it is not helpful in my scenario as I would first have to stop the service to be able to gain full access to the location where my build is generated to.
Whilst the service is attempting to restart before I do the restart of PC, when I attempt to build the service from my code, I get this interesting error from the compiler:
Error 16 Unable to copy file
"obj\x86\Debug\X_WindowsService.exe" to
"bin\x86\Debug\X_WindowsService.exe". The process cannot
access the file 'bin\x86\Debug\X_WindowsService.exe' because
it is being used by another process. X_WindowsService
Because of the error above I also think this is why I am not able to use the SO solution from here.
Does anyone have a clever idea for me to go through to bypass having to restart the machine as I debug and make changes to my codebase?
I also had a look at this link from SO but it has no marked solution, I also tried one of the Microsoft forums for a solution but it too has no applicable solution as they recommend the restart which I am trying to avert.
I feel so silly after finding this solution. I should most certainly have used the KISS principle for this one.
Turns out, all I had to do was look for the service's process from task manager and simply end the task. After that a refresh to my services list shows the service status as blank, meaning it has completely stopped without a restart of the machine.
How can I debug an windows service when it is starting?
I have an windows service that is falling to start and I add all the logs that I could but something is happening behind the scenes (between the installed service and Windows) that I cannot see (as far as my knowledge go).
I am not looking for code debugging here but windows message between the service and Windows, but I can't find any in event log, maybe I need to turn it on?
I am thinking that something between the lines of windows think my service is a virus, or windows is not been able to connect to my service by name, something like that.
Does anyone know how I can see this kind of information on Event Viewer or similar?
Debugging of Windows services is quite challenging as they are running in session 0 with no desktop and user interaction possible.
One way to debug your service is to setup a remote debugging session with windbg as described here.
Another way is to use my winsvcdiag tool which should make the process simpler and possible to debug from VS: https://lowleveldesign.wordpress.com/2015/06/22/how-to-debug-windows-services-written-in-net-part-ii/
And I'm not sure what type of event logs you want to see. When a windows service is failing there is usually a brief message in the System log. You may always look if process monitor is reporting any errors for your service.
I'm trying to prevent our wix installers from prompting the user for a reboot when uninstalling. Our services are set to be uninstalled and deleted on an uninstall. Unfortunately for us the RestartManager is prompting the user that a reboot will be required during the InstallValidate action. This action occurs well before the StopServices and DeleteServices actions.
Checking the logs, it seems that the RestartManager thinks that our service is a critical process:
"Detected the application with id 1234, friendly name 'abc', service short name 'xyz', of type RmCritical and status 1 holds files[s] in use."
The services are installed and running under the local system account. I'm not sure but I think if RestartManager was returning RmService instead of RmCritical then it wouldnt be prompting for a reboot.
Any help much appreciated.
EDIT:
MSDN states that for RMCritical:
A system restart is required to complete the installation because a process cannot be shut down. The process cannot be shut down because of the following reasons. The process may be a critical process. The current user may not have permission to shut down the process. The process may belong to the primary installer that started the Restart Manager.
The user does have permission to shut down the services, and the services are not anything to do with msiexec so I can only assume that our service is thought to be a critical process.... but why?
You can suppress window's RestartManager by setting the MSI property MSIRESTARTMANAGERCONTROL=
"Disable" (see documentation here - http://msdn.microsoft.com/en-us/library/windows/desktop/aa370377(v=vs.85).aspx). The only problem with this approach by itself is that instead of prompting users with a reboot-required dialog, they will see the file-in-use dialog (and be asked to shut down any applications that might be using those files/services). This dialog is displayed during the InstallValidate standard action of the InstallExecute Sequence.
If you want a sneaky way around either of these dialogs you can schedule a custom action before InstallValidate that manually shuts down any running services before the RestartManager has a chance to inspect the system. This does not follow standard MSI practices because normally you would mark a custom action that modifies the system as a 'deferred' action, but MSI doesn't allow any deferred actions to run before InstallValidate. So, you would have to mark the action as 'immediate', but in the code you would go ahead and modify the system by shutting down the services. The drawback here is that there's no such thing as an immediate rollback action, so if your uninstall/upgrade fails and does a rollback the services you stopped will be left in a stopped state. The upside is that users never have to see any additional dialogs during their uninstall/upgrade.
Ran into this also.
The problem is that the restart manager does NOT think the user has permission to stop the service even though it does because at the time that it checks (InstallValidate), the install has not elevated yet.
My solution is to give the Users group permission to start and stop the service. I used the sc sdset command to change the service permissions.
Or you can use a bootstrapper to start the MSI after elevating.
Restart Manager will not normally prompt for any files-in-use situations for services that are marked to be stopped in the current operation. In other words it goes through the ServiceControl table to see if the service will be stopped anyway, and will not automatically prompt for in-use files.
Unfortunately this behavior was compromised at one time by a bug - only the first entry in the ServiceControl table was checked. I don't know if this bug was ever documented so I can't cite anything. The original question was posted in 2011, so I would assume that this particular issue has been corrected. The only issues of this kind that occur now tend to be situations where the service is multi-process in some sense, or jacketed (some java services are like this) or when the service does indeed stop being a service but the containing process does not complete promptly, or the ServiceControl doesn't do a full wait and it is still in fact running.