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.
Related
I had a program that starts up a Windows Service when installed and deleted that Windows Service when uninstalled. However it refused to uninstall after I modified the installer by accident (my fault!). I couldn't even remove it from Programs and Features as it kept throwing an error 2715. I found this article that had a FixIt program: https://support.microsoft.com/en-us/mats/program_install_and_uninstall
Using that, I managed to finally remove the program itself. Now however, when I try installing and uninstalling it again (to test my changes), the Windows Service that's attached doesn't get removed. In fact, it continues running. I checked the registry and indeed the key for the service is still there after the uninstall. I would need to manually stop it and do a sc delete to get rid of it. Any idea on how I can solve this?
Edit: I am able to replicate the issue on another computer. What I do is, I install the program there, and use the Fix It tool to remove it. Once this is done, I can easily replicate the issue as the service is never deleted after uninstalling. It works fine prior to this.
Some guesswork here because there's not enough info....
Eroor 2715 is a Windows Installer error, and I suspect it's related to you running a program (as you describe it) to start and stop services. I'm guessing that you run it as a cuatom action, and on uninstall you attempt to run it but it's missing because it's been uininstalled.
So:
That fixit cure is not for a broken MSI (which yours is) - it's for fixing corrupt registry data that prevents uninstall, not fixing a broken MSI uninstall.
You don't need to run code to start and stop and delete services. Most MSI-building tools have support to the the Windows Installer functionalty that does this for you, so stop doing it!
A more specific answer is difficult without knowing what you are using to build your MSI with, and how you're running your program, but the signs point to you running the program after it's been removed, and even if you get the program running properly there's no way to tell whether it is correct without seeing the code. But 2 is what you should be doing anyway.
I have a simple msi written in WiX that installs a native NT service. After I have made some changes in the msi it fails at StartServices standard action with the error "service failed to start, verify you have sufficient privileges". If I press Ignore and start the service manually then it start successfully. The problem is definitely not in insufficient privileges. How can I diagnose/debug such issues? The verbose logs of the Windows Installer seem to not contain any helpful information.
The installer won't have any useful information because the error is only surfaced by the installer. Here's how I approach this.
Comment out the ServiceControl element so the installer doesn't try to start the service.
Run installer and all it to finish.
Manually start the service.
If the service starts, this indicates some type of race condition. One common scenario is the service has a dependency on a file being installed to the GAC or WinSXS. The installer puts these files there using the PublishAssemblies standard action. However since the GAC and WinSXS APIs don't support transational installation, PublishAssemblies waits until the commit phase to perform the work. This is after the installer attempts to start the service. Another common scenario would be if you had some custom action that was installing or configuring something that the service needed and you were doing it to late in the installation.
If the service still won't start, this generally rules out race conditions. You have to profile the service itself. Use tools such as depends, ildasm (if .net) and processexplorer (filemon / regmon ) to try to discover what the missing dependencies are. Update the installer then rinse and repeat.
As you've found, the Windows Installer does not provide useful information when it fails to start a service. However, when the dialog is displayed the machine is in the perfect state to determine what is going wrong. So, rather than cancel the install, start debugging. Try to start the service and see if that gives you more information. If not, break out the debugger and go to town.
I basically follow the process described in this FireGiant KB Article. This is the most direct approach to figuring out why the service fails to start. It's too bad the Windows Installer just couldn't provide better messages itself.
I deployed my service package into Windows Azure. Management Portal has been showing "waiting for the role instance to start" for 30 minutes already so I assume something is wrong.
I know that there's Azure Diagnostics, but is there some easier way to find what's going on in my instance - like some console displaying some detailed output or something?
In these cases, it is probably the most expedient to simply RDP into the box and see what is going on. Event logs, hitting the site, etc., from inside the machine usually gives you a pretty good idea. If you have Intellitrace (Visual Studio Ultimate), you can also enable that and suck down the logs to see what is happening. That works very well also.
#dunnry The problem is that you can't open a RDP session to the server if your Azure Role is not running, so you don't know anything what is going on.
Most of the times there is something wrong in your Azure Configuration files. Try removing parts and redeploy afterwards. Pay triple attention to your ConnectionStrings. Make sure that the ServiceDefinition ConfigurationSettings are all defined in the ServiceConfiguration ConfigurationSettings File.
What we basically do is to deploy on a nightly build basis. We can check our ChangeSets of the day before after an instance is not reaching the running state.
If the Azure Diagnostics doesn't tell you anything then I don't think so - no. Somewhat annoyingly, one thing that frequently causes problems is Azure Diagnostics initialization - e.g. if the diagnostics connection string is wrong.
If the role instances start but the app has problems then the remote desktop might help.
If all else fails, try Azure support - it's still free right now.
I have created a windows executable with some custom actions and some UI stuffs.
I am facing a strange behavior with the installable.
I tried probing through the code and kracking the installer as much as I can, but I did not find any idea why the strange behavior is available.
So, I wanted to debug the installer at every point of code execution in the Custom Action for which I tried writing those values I require to a logger. But unfortunately my logger will get created after the installation at which point I will not be in a position to run it again.
So, can anyone suggest how to debug it while the installable is under execution?
I've tried but couldn't get a debugger working with Installshield universal.
My workaround was to add a lot of debugging messages and to use VMware. Install VMware and create the test machine as a virtual server. I configured the virtual server with all the prerequisites, rebooted it and then ran a snapshot.
After the snap shot I'd run the install script, wait for the errors and the log files. Then I'd use the VMware 'revert to snapshot' function to go back to a clean instance of the test server and start investigating the error messages from the logs.
The title says it. I'm looking for a way to determine exactly which file/registry key this executable is attempting to access. I have attempted to use Windows auditing capabilities and Process Monitor to determine where the failure is happening but, this failure does not produce audit failure events or show as access denial in Process Monitor.
Of course, If someone has experienced this and can provide a solution to resolve the error directly that would be almost as nice.
Background:
I am using moveuser.exe which is part of the Windows Server 2003 Resource Kit Tools to convert the security of local user profiles on a number Windows XP workstations.
Symptom:
Occasionally, moveuser.exe will fail to convert the security of a profile with the error "Error: 5 access denied". I have not been able to determine any commonality among the failing accounts or the computers they reside upon. A given computer may have host 6 profiles, 5 of which convert without issue and 1 which produces the error.
There are a few factors that I'm as sure as I can be about:
-The account I'm using to run moveuser.exe with has full Administrator rights to the local machine and the domain to which the profile security is being converted.
-The failure is not related to file permissions within the profile directory (the entire directory can be moved, renamed, deleted, or successfully converted via a workaround).
I've developed a reliable workaround for these cases but, it is fairly involved and I would much rather understand the root cause of this error and correct it pre-emptively.
My workaround (glad to share it, left out for brevity) seems to indicate that the failure is related to HKEY_LOCAL_MACHINE \ SOFTWARE\ Microsoft\ Windows NT \ CurrentVersion \ ProfileList registry keys but, I cannot determine exactly how/why.
Did you try to use the "regini" command line tool to grab registry permissions for the administrator account?
Use FileMon and RegMon (now Microsoft, formerly SysInternals, still free) to monitor what exactly is being accessed, how, and what rights/access are being requested.
I don't have a URL handy, but a Google search should be able to hook you up with these tools.
A couple items I would try. First, could it be that the user was logged in and the computer hasn't been rebooted. Microsoft has a product called UPHClent which helps in unloading unneeded user hives.
Next thing I wanted to know, is if you try rebooting before running the moveuser executable. This Conversation seems to indicate this would help with this kind of error.
Two days after posting this I got to the bottom of the problem. It turned out, just as Rob Haupt suggested to be related to a stuck user hive. The program I was running, moveuser, was reading the Refcount key found under HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ ProfileList\ <SID>\ and ending immediately.
Setting Refcount to 0 solved the problem immediately
Pushing out UPHClean to all the target machines pre-emptively has all but elimated the problem and we were able to successfully convert profiles on several hundred machines over the last week.
An important note about UPHClean:
I'd tried installing it previously but, it didn't appear to help. I was too impatient, the UPHClean ReadMe revealed that the service just takes time to do its job.