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.
Related
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.
I'm trying to use this Visual Studio extension for 2013, which recreates the built-in installer functionality from Visual Studio 2008/2010: http://blogs.msdn.com/b/visualstudio/archive/2014/04/17/visual-studio-installer-projects-extension.aspx?CommentPosted=true&PageIndex=2#comments
It works, allowing me to edit the project as before. It has the install and uninstall commands when right-clicking the install project, too. It installs fine.
When I try to uninstall, though, I get the following error and then the uninstall rolls back:
Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Wow6432Node\Microsoft\
EAPSIMMethods\18\FastReauthContext. Verify that you have sufficient
access to that key, or contact your support personnel.
I am not doing anything with that registry key, and there don't seem to be any relevant results on google-- at least not in the normal top 5 pages. Does anyone know what causes this or how I can fix it?
While I am not able to uninstall, I am able to increment the version of the package and allow it to remove the previous install and install the new version (all at once) successfully.
I am using Windows 8.1 Pro 64 bit, the projects are compiled for <AnyCPU>, and the installer is configured for x86.
EDIT I am running Visual Studio as Admin. When uninstalling from the Control Panel, I am also clicking the 'allow' button in the UAC dialog window that pops up.
I know how to give myself access to a registry key (permissions). I want to know why this key is trying to be removed. I support this app on several machines and I don't want to have worry about remembering an uninstall hack in the future.
EDIT This only seems to be an issue for a 32x installer on a 64x OS or a Windows 8 issue. I was able to use the same 32x installer to successfully uninstall the app on a 32x Windows 7 machine.
This must be an environmental problem, that key doesn't have anything to do with installers. EAP-SIM is an authentication protocol for wireless networks. The FastReauthContext key almost surely was meant to avoid having to provide a username+password each time your machine reconnects to the network. Which makes the registry key content very sensitive of course, it can only be read by a service that runs with the System account.
So, something goofy going on with your networking setup. Verify that you can successfully reconnect to such a network. If you used a VPN before then make sure it is active again. Something like this. Update your question with anything that might be relevant to networking when you first installed the app.
I have had similar problem and what I found out this is caused by MSI attempting to delete whole "Software\Microsoft" section in the registry. Lucky you that it encounters this error and rolls everything back.
So the solution is the following:
Since you have installed your program whenever you try to uninstall it the system will run msi from cache that is usually located C:\Windows\Installer.
Find your package in the cache. Here is an article that may help you http://csi-windows.com/blog/all/27-csi-news-general/334-identifying-cached-msi-packages-in-cwindowsinstaller-without-opening-them
Open the package in Orca. You must do this as administrator.
Go to Registry table and find record with "Software\Microsoft" as a key. Most likely the Name column will contain either "-" or "*" value. This means that during uninstall MSI will try to delete whole "Software\Microsoft".
Either change the Name value to empty or "+" or try to change key to something like "Microsoft". The second option will cause that installer will not find the key to delete during uninstall, but it will skip this error and let you uninstall your program.
You installed an untested installer on your dev machine? Speaking from experience, don't do that! Snapshotted VM's are cheap and will save you from this sort of pain.
Visual Studio Deployment Projects (or VSI as it's now called ) is known for creating very poor quality installs. The combination of those two put you where you are today.
I would need to look at the full uninstall log and your MSI using ORCA to understand exactly what is going on. MSI Zap and a manual cleanup of resources is probably required at this point.
I got a weird problem with my VB app that has got me very confused. I am updating an existing program. I had to add some processing queue capabilities. On my system, unit testing worked great but when I compile it and run it on a different computer (a network server machine) it first tries to open an office install. If I cancel this, the program seems to run fine. The problem is that this program will be run in the background and I can't be hitting cancel each time it runs.
So my question is this: what is going on here? I'm usually a java developer we eclipse so I'm used to being able to include all the needed libs into the jar files automatically. It doesn't seem like the case with VB6. it seems like it expects all the same libs to be on all the systems. Is there any way to tell what might be triggering this?
The only thing I can think of that is causing it is that I'm using the "OpenProcess" function in the kernal32 lib. that the only major change I have made.
any help would be very appricated. thanks!
EDIT:
It seems that multiple versions of word were installed on the system and it was screwing things up somehow. We uninstalled one and it fixed it.
I ran into this a while ago and it was related to my installer for the VB6 app overwriting some system files for Office that it shouldn't have. Any time one of the System dlls was accessed Windows would determine that something was wrong and the Office installer would start up.
The short-term fix was to let the Office Installer repair the broken chain of dlls.
The long-term fix was to never overwrite built-in Windows System dlls.
You could also check out the Microsoft Fix it Center.
Visual Basic 6 is crashing after a new build of my program. Whenever I Start (F5 or Ctrl-F5) my program after making changes to the code, VB6 crashes with the following message:
An unhandled win32 exception occured in VB6.EXE [XXXX].
I can't make any pattern out of XXXX. It's been 5168, 5012, 1488, etc; it changes every crash.
The JIT debugger then offers to let me debug VB6 in VS2010 (which shows nothing but a bunch of disassembly.) If I say no, VB6 shuts down. I can then open and Start my program immediately, and it runs just fine; my changes from before the crash were saved. Alternatively, I can make changes, save them, exit VB6, restart VB6, then run them without a problem. But it seems like as soon as I make any changes, a "crash" flag is set, and if I try and build it before restarting VB6, it simply dies.
I'm only having this problem with specific projects. Most projects work completely normally. It's just this one, and it's branch, that both act in the same manner.
Does anyone have any clue what's going on? Obviously, saving works. And building works. And running works. They just don't seem to work together.
I reinstalled VB6 to no avail.
I ended up on this page after installing VS2010, and just one of many VB6 project wouldn't compile.
Simply go to Project Properties / Compile tab, and uncheck "Create Symbolic Debug Info".
Hope it works for you.
Try to open vb6 project with compability mode as XP. We had some issues related to "make exe" command. Then I started to run VB6.exe with XP compability mode.
Since you're asking for any clues, possible clues may include:
The surprises VB6 experiences when run on Vista/7. Try running elevated/remove elevation.
Same, but applied to a third party ActiveX control you're using.
Not having the Service Pack 6 installed. Install it.
Subclassing issues. Make sure your subclassing, if any, is actually correct.
Whatever problems you'll never figure out. Try reinstalling.
Reinstall VB6, delete the workspace files and then create a new project adding in all your current code files. Then go out and get a job where they use a modern SDK :)
it starts up windows installer with random applications on my machine . . after i click cancel a few times, it loads vb6 fine.
any ideas why this is happening?
To stop this behavior:
Start VB6
Open the Add-Ins dialog
Uncheck the "Visual Component Manager" Add-In
Source:
After VS2010, SP1, VB6 launches VS2010 installer
This is what a Windows Installer repair looks like. It means that something is broken in one of the installed products on your system. Ideally it's a one-off repair so you might be better off letting it runs its course and do the repair, except of course if it asks for a install CD that you don't have.
The Windows event log (Application) will have MsiInstaller entries saying what product and component has the problem.
It's possible a previous installation has not completed correctly.
Use the utility at the following link to remove any rogue installations files:
http://support.microsoft.com/kb/290301 (broken link Aug.2017, leaving URL for "historical purposes").
As PhilDW has pointed out this is a Windows Installer Self-Repair issue, and can often be resolved by allowing the self-repair to complete once. At other times the problem persists and it should be fixed by other means. Even when the self-repair completes and the problem goes away, it can still resurface once you launch the conflicting application. Windows Installer is not easy to deal with.
In your particular case you might be able to get away with a "workaround" rather than a fix. By locating the main VB6 EXE file on disk (in its main installation directory) and manually creating a shortcut to it on your desktop, you might be able to successfully launch VB6 via this new shortcut without the self-repair kicking in. It might be worth a try.
This shortcut trick will not remove the underlying problem, but might help to "bypass it". Just for the record: the reason this might work is that the new, manually created shortcut is not "advertised" and will not trigger a key-path check of the installed product when launched. This is Windows Installer's way to verify that a product is correctly installed. Note that even if the workaround works, self-repair might still result during application use because of faulty COM data being detected (which is very likely the cause of the whole problem you are seeing, but give the manually created shortcut a try).
There is a rather comprehensive "article" on self-repair here: How can I determine what causes repeated Windows Installer self-repair? which might help to track down the cause of the self-repair kicking off in the first place, but fixing it can be a rather complicated process (so try the workaround first). It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop. The last application to launch will overwrite the registry or file system with its own setting.
This worked for me, for VS2010 RC:
"Please wait while windows configures Microsoft Visual studio 2010 Ultimate."
THe work around that fixes the issue for me was to run the following via the admin cmd prompt.
Md "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\common7\IDE\FromGAC"
from http://social.msdn.microsoft.com/Forums/en-SG/vsprereleaseannouncements/thread/572a0f8a-16b0-4e1d-b581-16be36a9b564
This was also happned to me.
Whenever i tried to open vb6, it started windows installer to configure "Autocad".
Autocad had not broken. and it was working fine.
I tried removing and reinstalling Windows Installer, But it did not solved the issue.
Then i installed Microsoft's "Windows Installer Clean Up Utility 2" from given link.
Using this utility i removed the autocad from "Windows Installers" Database.
After that VB6 never started installer again.
Keep in mind 'removing any entry from installer's database may be risky, but i had no choice. So do it on your own risk.
Download "Windows Installer Clean Up Utility 2" (this is a deprecated, unsupported and unsafe tool to use - Aug.2017. I will leave the link in for "historical purposes", don't use it).