I created a Windows installer for a Client-Server program by using VS 2013 and InstallShield LE 2015.
I log in to a computer as Admin and run the installer. All works fine.
Then I modify the registry for Local_Machine for some keys to define the database location etc. for the program (this was done by the installation initially as well, but due to certain issues discussed in At each login the program tries to configure installation parameters in the HKEY_LOCAL_MACHINE registry, I removed the registry modifying section from the installer).
I then run the program by double-clicking the shortcut placed by the installer on the desktop and test it. All works well.
Then I log off the computer.
Another user with admin rights logins and clicks on the shortcut, and the problem comes: the program starts to reinstall itself!
Then it fixes itself and runs fine.
But If the first user logins afterward, she experiences the same reinstall operation so does the first user afterward ad nauseam!
So, even though the installer does not create any registry items by itself, somehow, as soon as the program accesses the registry, or whatever it thinks broken, the Windows OS intervenes and tries to repair whatever needs fixing.
The InstallShield LE does not allow setting shortcuts to be "Advertised Shortcut", or
I delete the shortcut created by the installer and recreate it manually after the installation and yet experience the same problem. So the nature of the shortcut possibly is not the cause.
This problem only happens for multiple logins to the computer. If many people login by using the same credentials, it never happens.
So, what's wrong? I studied many StackOverflow answers to resolve this issue with no success. Any help would be highly appreciated.
Stein gives a good set of instructions on how to diagnose problems with MSI programs in this StackOverflow answer. When I followed his instructions, I was able to check which component of my MSI program has a problem. It turns out, the serial bus controller library, MScomm32.ocx could not register under Win 10 properly. Once, I implemented the solution in this link, the above problem resolved and I could log in as two different users without initiating a reinstall process whenever the program icon was double-clicked to run.
Related
Not really sure of my exact question, but here is the situation:
I have an application (WinForms, C# .Net) that I am developing in Visual Studio 2012. It does a lot of things but the important bit is that it needs to read files from a certain location.
In this case, the location of the files is on a server and my machine has a mapped network drive setup for accessing the files. I can manually navigate to the files with Windows Explorer fine.
I have the following line in my code which is highlighting the issue:
System.IO.File.Exists("X:\\A Folder\\a_file.txt");
And that file does exist in that location. However this is where the problem occurs: if I build the solution and run the .exe directly from the "bin" folder (double-click). The code is fine, and it finds the file. But if I run it with visual studio then I get a "file not found" exception.
I am putting this down to the fact that Visual Studio is running in "Administrator" mode (I forget why I needed this, but I do). Now this makes sense if you consider that the "administrator" account does not have the "X:\" drive mapped. However, this has never been a problem until I upgraded to Windows 10 last week.
So my question is:
Does Visual Studio Administrator mode work differently in Windows 10? In this case, does it handle mapped network drives differently?
It's worth noting I upgraded from Windows 7, so I cannot confirm if this issue is also present in 8 and 8.1 or not.
And before anyone asks, let's just say it has to be a mapped drive. No UNC paths allowed!
So I have found a solution/workaround. Kind of seems like a wasted bounty now, so if someone has other suggestions that are better then please post and I will review them and award as applicable. Or even if somebody can make a more detailed version of my solution then I will award that one.
The issue is probably not specific to Visual Studio, but would occur with any application running with elevated privileges. Anyway, the solution I found is to add a registry key that enables the same shared drives to be accessible when running in administrator mode.
The registry key location is:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System
And the key to add is called:
EnableLinkedConnections
And should be created as a DWORD with a value of 1 (0x00000001)
I checked with the machines running Windows 7 and they do NOT have this key, yet they still work fine. So I expect this isn't the only solution, but it does seem to work (no side effects noted yet). I would assume that Windows 10 has a specific setting somewhere that by default prevents mapped drives from automatically being available with "run as administrator".
For reference, I found this information here.
In fact, here is a more "official" recommendation for using this reg key.
This is unlikely to have anything to do with Windows 10, just with the configuration of your machine. What you describe is normal and covered by this KB article. Nothing I can check for myself so just try the recommended workarounds, follow up at superuser.com if necessary.
Different users/system tasks maybe running. As such, you have the X drive mapped, but others do not. You could do the drive mapping on additional users on your Windows installation as well. As you stated, this should not be a Windows 10 only issue, but also Windows 7+ and elevated privileges.
Maybe you could use a configured parameter for the X: path and load at runtime, or even try using UNC paths which will resolve at runtime and not need the drive to be mapped.
\\ServerNameOrIP\A Folder\a_file.txt.
In the code, you would need:
System.IO.File.Exists("\\\\ServerName\\A Folder\\a_file.txt");
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.
When I launch an application, a windows installer from a previously installed program keeps popping up. The program still exeists in the Server and it's working fine. The installer popup, after clicking "cancel" will eventually dissapear.
I'm not interested in solving this problem, I'm just wondering how does the windows installer decides what to install? I mean to say, what's the mechanism? How and who triggers the windows installer?
Thanks for any reply!
This is the self-repair mechanism triggered automatically by the OS. Along with the above enumerated reasons it can also be triggered if:
A feature having been installed as advertised/install on first use/install when required
Files inappropriately shared between components, features, or products, which can lead to the resource being uninstalled while a product is still using it
A product with per-user data having been installed on a multi-user system by one user and then launched by another user
To investigate the resource whose absence triggers self-repair, look in the Application section of the system's event log. Self-repair events are displayed with source "MsiInstaller".
If the installer is indeed trying to add a resource required by another application the best solution would be to let it finish, and it should no longer appear after that.
Usually this behaviour appears when one of the following is true:
the install process was not completed successfuly
the registry entries for this program were deleted / corrupted
(not finding an appropriate registry entry is a trigger)
the install program's updatemanager was corrupted / disconfigured / cancelled on the previous run
The solution usually is to completely uninstall the program, to check that all folders and registry entries were indeed removed and then to re-install the program.
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).
I have a VB6 app that formerly worked perfectly on a Vista machine as a scheduled task, but it will no longer open on the same machine. The app generates export files in a specified folder with no direct output on the screen. I get no errors, no missing references, just absolutely nothing.
The machine is running Vista Business 32-bit, UAC is disabled with a single administrator account, and automatic updates are turned off. The app resides in a non-protected folder, and the export files are put in a folder on the desktop. The client swears that the only change they made to that computer since I installed this app was installing Norton Antivirus, which has never caused problems before with our software.
In addition to the normal VB6 references, the app references Microsoft Scripting Runtime (scrrun.dll), and Microsoft DAO 3.6 (dao360.dll). Both of these files are present and registered on the target machine, along with all the other VB6 dependencies. I added MsgBox statements at the beginning of Sub Main() just to see if anything is being executed, and its not. Disabling Norton yielded no results, nor did reinstalling VB6 runtime to rule out any corrupted libraries. Not once did I get any messages, error or otherwise from my app.
I've never had an issue like this before and I'm completely stumped. Is there anything else that could be causing this?
Edit - The app does not run even when I run it manually, so the part about it being a scheduled task is irrelevant to my problem, sorry for including it.
The user has full administrator credentials, no compatibility mode was needed on the initial test which at the time, was done on this very machine I am having the problem on. For grins I tried compatibility mode for XP and 2000, still nothing.
Try to inspect - if you can access them - the Event Viewer messages. Maybe you will find some tell-tell signs in there...
You could try running the program in Windbg, a free standalone debugger from Microsoft. Compile your VB6 EXE into native code with symbols (create PDB files) and you will be able to debug your application in Windbg.
I would guess one of two things will happen.
Windbg will fail to load the EXE. Presumably with an error message that will identify your problem.
Windbg will load the EXE, and you can single-step through to see what happens.
Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft VB guy with a brief introduction to Windbg.
Has the user changed their password? That will cause the scheduled task to fail until they re-enter the password on the task.
Have you tried running the process directly, instead of as a scheduled task? I'm far from an expert, but it may be that any errors being generated are not showing up because the program is running as a task.