vb6 activex document project silent install - installation

I have a vb6 activex document project and I need to create an msi package (thats what is the requirement since it has to be deployed thru active directory) that runs without any user interface and user intervention. I followed these steps:
I created an msi project using visual studio installer and removed all the user interfaces. Added all the vbd files manually to the project, compiled it. When I run the msi, it intalls all the files without prompts but the application doesn't run.
I created a package using package and deployment wizard, then opened the source code of vb pdw project, commented all the message boxes, assigned default values where required. Then compiled setup.exe file and copied/overwrote it with the setup.exe on the install package created earlier. When I run it from command prompt like this 'setup.exe -s install.log' it installed the application without prompts, works well. And the application runs well after installation.
So I decided to create an msi package using visual studio 2008 and added the above created install package (using package and deployment wizard). In custom action I set the setup.exe to run with '-s install.log' arguments. I need one registry entry that holds the App path, so I added it on the registry settings section.
Another requirement is I need to run another self-extracting exe after the installation. And that self-extractor will look at the above registry entry and extracts (overwrites) the file on the App path.
So using custom action, I set the update.exe to run after the installation.
Now, when I run the msi, it runs well, and after installation it runs the update.exe, everything works well; but only sometimes. I couldn't predict when it works and when it doesn't. When I tried the same msi on few other machines, it worked on some and not on others.
And when I checked the 'Add or Remove programs' there were many entries for this App.
I have been struggling with this msi project for a while and now I feel helpless. I don't know what I'm doing wrong. I would appreciate if anyone could point me in the right direction.
Any other way to create an install package for vb6 activex document project without prompts?

This works for me using MSI to install an ActiveX dll document:
This reply is a bit late, but I also struggled with this for about
a year before getting it to work. The key seems to be in registering the ActiveX
exe or dll when installing on another PC. The following works for me; am only
listing steps for a dll as still haven't succeeded 100% with exes:
Create your ActiveX dll Document (you can have forms with dll just like exe)
Use VB Package and Deployment to gather the necessary files in one place.
Be sure to use the safe VB system files (download a zip file [vb6sp6sys.zip] of them from http://www.jrsoftware.org/iskb.php?vb) in place of those
generated by VB's Package and Deployment wizard.
Use VB to create the small executable (make sure Startup Object is
Sub Main) shown below in the code section. Because Internet Explorer is the "container" for your ActiveX document, this little exe uses a version of it
(IE) to load your UserDocument1.vbd, DEPENDING ON WHICH OS you are using. Windows 7 and, I assume Vista, use a different version of IE by default, which doesn't seem to want to run an ActiveX document. But, in their Program Files (x86) there is a version of IE that will - hence the test on whether the (x86) folder exists or not; if not it assumes this is a lower version of Windows and runs using the normal IE. Call this small executable something like "SilentStartUp_ByOS.exe"
Now the bad news: You need to buy Advanced Installer to use its Professional version, which is needed to extract the registration info from
the native library of your DLL and any included OCXs. There is a free version
of Advanced Installer, but it doesn't have this capability.
Note: There may be other installation packages that will do this also, but
Advanced Installer is the only one I know about. I'm an Inno fan, but couldn't
find any way to do this with Inno.
Include all the files from 2. above, along with the exe created in 3. in
your Install package. Assign an icon to the exe created in 3. using Advanced
Installer and make it a shortcut to start your program.
Be sure to install everything (using the Install Parameters screen) in the AppDataFolder\AnyFolderNameHere instead of the ProgramFilesFolder
for the sake of bypassing Security issues which are very strict on Win7
and Vista, not to mention if installed on a company intranet.
When all is done, because your dll was registered, IE should be able
to start up your ActiveX document.
Code:
Sub Main()
Dim strTemp As String
'ok, it may be Vista or Windows 7...
strTemp = "C:\Program Files (x86)\Internet Explorer\"
If CheckFileFolderExists(strTemp, False) = True Then
'ok, use older version of IEXPLORE to run this on Win7 (or Vista)...
Shell "C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE " & App.Path & "\UserDocument1.vbd", vbMaximizedFocus
Else
Shell "C:\Program Files\Internet Explorer\IEXPLORE.EXE " & App.Path & "\UserDocument1.vbd", vbMaximizedFocus
End If
End Sub
Function CheckFileFolderExists(strName, fFile) As Boolean
' The fFile variable determines whether you're
' looking for a File (True) or Folder(False)
' The strName variable holds the fully qualified
' path you're looking for
Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
CheckFileFolderExists = False
If fFile = True Then ' It's a file
If fso.FileExists(strName) = True Then
CheckFileFolderExists = True
Exit Function
End If
Else ' It's a folder/directory
If fso.FolderExists(strName) = True Then
CheckFileFolderExists = True
Exit Function
End If
End If
Set fso = Nothing
End Function

Related

Custom Action failing to execute during installation created with Installshield 16

I have run this custom action with Installshield Limited Edition for Visual Studio in the past and it has worked. But now when I try this with Installshield 2016, this custom action gives me a 1722 error and rolls back the installation. The log file doesn't give any more detail than "failed with error 1..." and the 1722 error.
My custom action setup via the Wizard -
Working Dir: InstallDir
FileName & Command Line: "[SystemFolder]cmd.exe" /c "[INSTALLDIR]somefilename.exe" "'%r' '%keyname=keyname' '%keydll=some.dll' '%appexe=[INSTALLDIR]differentfilename.exe'"
What this is supposed to do is run somefilename.exe from the command line, with parameters "%r", "%keyname", "%keydll" & "%appexe".
When I run it on the command line directly so -
"C:\Program Files (x86)"\somefilename.exe "%r" "%keyname=keyname" "%keydll=some.dll" "%appexe=C:\Program Files (x86)\differentfilename.exe" - it runs fine.
I think I am missing some quotes someplace and I have tried various combinations with no luck.
Any ideas what I am doing wrong?
Thanks in advance!
Thanks for the suggestions #PhilDW.
I could possibly take out the cmd jacket and just run the exe and try.
I finally got it working though, by changing some quotes etc. Here's what the final FileName & Command Line argument looks like:
"[SystemFolder]cmd.exe" /c start "" /d"C:\Program Files (x86)\foldername\" "somefile.exe" "%r" "%keyname=something" "%keydll=something.dll" "%appexe=C:\Program Files (x86)\otherfilename.exe"
Hope this helps someone.
A few suggestions:
You should post the verbose MSI log section relating to this because it should show the complete resolved command line, assuming that you have created a full verbose log and not a partial log.
It's not clear why you need to run this program with a cmd jacket. If it's a plain Windows program just run the executable as a custom action.
When you run from the interactive user explorer shell you get some infrastructure (such as working directory) that you do not get with a custom action started by an msiexec.exe process. This matters because you have not specified an explicit full path to some.dll, so it's not obvious it can find the file.
It might be useful to say something about where this custom action runs and its type. For example if it's turned into an immediate custom action (all VS custom actions are deferred) then it will fail because no files have yet been installed. Likewise, if it's deferred but somehow before the InstallFiles standard action it will fail.
All custom actions run by Visual Studio generated projects are deferred and run with the system account in a per-system "Everyone" install. If your custom action requires elevation then it must also be deferred and the MSI must show a UAC elevation dialog, because otherwise it may well run but fail with access errors. It may have become a non-elevated per user install.

Registering a .NET DLL with Regasm using Powershell fails

With visual studio 2012 I created a DLL file in C# which can be used in Access 2013 by referencing it. This all works fine. I Created the DLL and registered it with CMD doing: RegAsm.exe -tlb -codebase C:\MyFolderX\MyDLL.dll
This all works fine, but because the DLL needs to be registered at multiple computers I wanted to do this with 1 click instead of doing it manually at each user computer.
Because users already use a BATCH file to launch the Access frontend application (which uses the DLL) I thought it would be wise to register it once when they use the BATCH startup. So to do this this I added the following in my BATCH script:
cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
RegAsm.exe -tlb -codebase C:\MyFolderX\MyDLL.dll
This sadly doesn't work because it has to be done in admin mode and checking the checkbox run as administrator just jumps through my BATCH code without doing anything for some reason.
So I though, why not use a Powershell script to do the same and launch that from my batch script.
To do this I created the following script:
#Register the assembly
$RegAsm = 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe -codebase -tlb'
$Assembly = 'C:\MyFolderX\MyDLL.dll'
Start-Process $RegAsm $Assembly
pause
This however keeps giving the error:
Start-Process : This command cannot be run due to the error: The system cannot find the file specified. At C:\users\me\Desktop\RegisterMyDLL.pst1
+Start-Process $RegAsm $Assembly
InvalidOperation: (:) Start-Process
FullyQualifiedErrorId : InvalidOperationException, Microsoft.Powershell.Commands.StartProcessCommand
I double checked the location of the DLL and it it just there.. Anyone have a clue what I am doing wrong? Perhaps some syntax error or quote to much? Already tried to escape my backslashes but this didn't had any effect.
Or perhaps there is an better way to achieve easy DLL registering at multiple users?
Does this work?
."C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" -codebase -tlb $Assembly

SCCM 2012 Application Deployment scripting issues, any ideas?

I had no problems with SCCM 2007 scripting application deployments, but SCCM 2012 has me pulling my hair out and I have very little left.
We tend to have heavily scripted installs and most of the time the installs fail in SCCM 2012, the latest failure is symantec enterprise vault, I wrote a script that would check the main DLL plugin version and use the correct uninstall string to remove the previous version, before installing the latest version.
my script is very simple and works fine outside of SCCM, but inside SCCM it fails.
If I recreate the application as a MSI deployment and use the MSI file then it installs fine, so SCCM is working correctly to the client. The uninstall that SCCM puts in from the MSI failed, but that is covered below in the example. I have checked all the client side log files and can not find any issue.
I even return the successfull install return code 1707 and 0 at the end of the script to try and get SCCM to make it a success.
I have written the script first in VB.net as a console service app and then rewrote it in vb script. both scripts fail. I used to use AutoIT to write scripts in the past, but that too was failing, so I thought I would switch to something more microsoft.
For detection I use the windows installer selection and point to the msi file where it picks up the product code.
deployment type is script.
The only thing I can think of is SCCM 2012 does not like the sleeps that are in the scripts.
or it just does not like scripts. :-(
The MSI uninstall failed, because it needed to run as administrator, as you can see from the script below, I run as administrator and this works outside SCCM, but not in SCCM. the install uses pretty much the same code but more logic and many more uninstall strings.
even the uninstall fails and here is how simple the uninstall script is;
Set WshShell = WScript.CreateObject("WScript.Shell")
If WScript.Arguments.length = 0 Then
Set ObjShell = CreateObject("Shell.Application")
ObjShell.ShellExecute "wscript.exe", """" &
WScript.ScriptFullName & """" & "RunAsAdministrator", , "runas", 1
Else
end if
Set objShell = CreateObject("WScript.Shell")
Set objExec = objShell.Exec("MsiExec.exe /x{ADEBB592-4986-4FD1-868C-D59DB32F0BC2} /q")
WScript.Sleep 8000
returnValue = 1707
WScript.Quit(returnValue)
Just because it works outside of SCCM, does not mean a lot if you have to make it work with SCCM! people make that comparison all the time a work and it means nothing, what you need to do, is enable verbose logging on the MSI, the command line it's something like this msiexec /x {xyz-code} /l*v c:\somelogpath.log, try it you may find something equally bizarre like a 1303 error inside the log files
Use PSEXEC and execute the command under system account.
I found some setups/installers do not like to be executed without GUI or other non-user account.
Another thing, in SCCM 2012 you have packages that just simple execute the program, with only exit code check.
And there are Applications that can have detection rules, which can be used to really verify if the program installed/executed correctly.
Also always check ITninja for tips.
Something like this you may need to make sure that outlook.exe is closed you may want to add a taskkill to your script and then try it:
taskkill /IM outlook.exe /T
msiexec /a "path to file" /qn
might work as a simple .cmd file
This is an old thread, but maybe this is helpful for people searching the web:
SCCM Applications usually run as SYSTEM, no need to "run as administrator" (you could configure that within the Deployment Type).
You cannot "break" out of SYSTEM context and do a "run as"
runas and system account.
Tried that once and finally did an ugly workaround by creating a scheduled task that runs under a specific user, then ran that task from my script, which is running as SYSTEM.
As already mentioned, test your scripts interactively using SYSTEM account:
psexec.exe \\localhost -s cmd
Check with whoami that you're running the cmd with SYSTEM.
Make sure you add the COMPUTER account of your test client to the share/folder ACL of your networked scripts folder, otherwise the system account does NOT have access rights.
If running the script as SYSTEM works but SCCM still reports an error, chances are high that the Detection Method failed, NOT the actual install!
Check the following logs here: C:\Windows\CCM\Logs
(See 4. below how to use the index service to speed up troubleshooting logs.)
AppDiscovery.log
AppEnforce.log
AppIntentEval.log
Open up the Windows Indexing Service Options. Configure *.log to index file contents as well. Then add the path C:\Windows\CCM\Logs to the index. Howto.
This way you could easily search for the application name and you will find all log files which deal with that application. You will also find the matching AppDT ID, so you could search for that ID and will find even more info about your package/application.
On your admin machine create a new log collection folder, add this folder to the index. This allows you to copy the whole log folder of a client to your admin folder. A few minutes later it's indexed and fully searchable on your local machine!
There's a tool available from Microsoft which could gather a full log package on a client: ConfigMgr Support Center
Do you have SCCM setup to run it as administrator in the program that you defined?

P2 self provisioning RCP vs. Windows UAC

We used to savor the joy that is a self updating Eclipse RCP application on Windows XP (it´s an company only internal document management system). Now after switching to Windows7 updates will only be performed if the application is run as an Administrator which of course erases the joy out of the thing that is a self updating application.
The self provisioning is more or less copy/paste from this article
Since the installation folder is bound to C:\Program Files (company policies...) the application may no longer write to this folder, unless started as an elevated process. What p2 does (at least I think after an epic debugging session) is to download artifact.xml and content.xml from the p2 repository to compare locally and build an update plan. Unfortunately if it is not able to store the downloaded files it simply says "Nothing to update".
I already tried to give the shared installation/bundlepool a try, in which the bundles are installed to the user directory using the p2 director application with the following properties:
-metadataRepository http://someserver/updatesite
-artifactRepository http://someserver/updatesite
-installIUs my.application.id
-roaming
-destination "C:\Program Files\MyApplication"
-bundlepool C:\Users\me\MyApplication
-profile DefaultProfile
-profileProperties org.eclipse.update.install.features=true
-p2.os win32
-p2.ws win32
-p2.arch x86_64
-Declipse.p2.data.area=C:\Users\me\.p2
The installer works kind of well and the application may start (after telling her, that the launcher is in my user directory). But unfortunately the self provisiong still doesn´t work this way. Run as administrator will result in downloaded updated bundles and features in the -destination location instead of the -bundlepool location - which is what I expected.
What switch did I miss?
We've had a similar problem here. One of the reasons may be that the IUs being installed still try to write something in the "C:\Program Files\MyApplication" via the p2.inf touchpoint instructions. The solution was to deploy a minimalistic launcher "C:\Program Files\MyApplicationLauncher" which:
performs bundle pool updates (dir = "C:\ProgramData\MyBundlePool")
and actually installs and launches the application in the %tmp% (dir = "C:\Users\username\AppData\Local\Temp\MyApplication")

PostgreSQL 9 install on Windows: "Unable to write inside TEMP environment path."

I am attempting to install PostgreSQL 9 (postgresql-9.0.3-1-windows.exe) on my WinXP machine and get the following error at the start:
Some googling around yielded some advice that suggested Windows Scripting Host might be disabled. I've checked and WSH is definitely enabled, so it must be something else. Question is, what?
I can see a file called prerun_checks.vbs is created in %TEMP% and when I try to run this manually, I get the following:
Which looks like a permissions error. However, I am an Admin, and I've given myself full control of the temp folder and it's still not working.
Any help appreciated.
In my case the solution was related to NotePad++ being the default application for opening .vbs files. If you have the same situation, here's an elaborate solution:
http://igordcard.blogspot.co.il/2012/03/unable-to-write-inside-temp-environment.html
In a nutshell, in the registry, you need to go to HKEY_CLASSES_ROOT\.vbs, and set the (Default) entry back to the string VBSFile.
This is a an old thread, but I just had the same problem on windows 10:
Unable to write inside TEMP environment path
Solve by the following steps
Check that the problem is related to Windows Script Host.
From cmd run wscript.exe
If you get an error Windows Script Host is not enabled then you can solved it by running the following from cmd
Fix for Current User
REG DELETE "HKCU\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Fix for Local Machine
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Now you can install psql
As I was finishing off my question above, our IT chap turned up and knew what the problem was immediately: it's McAfee. It prevents anything from running in a TEMP folder, including Windows Scripting Host scripts. Disabling McAfee for the duration of the installation fixed the problem for me.
So if you see this problem, try disabling your anti-virus.
The answer in the following page helpped me.
http://forums.enterprisedb.com/posts/list/3040.page
run-> regedit and take backup of registry using export
HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8} -> InprocServer32
Modify registry entry with new value as C:\Windows\System32\vbscript.dll
In fact, I found there are 3 entries of HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8}, and set the first one as above, it works.
If anyone else is searching for information on this and doesn't have any luck here, you might want to look at:
http://wiki.postgresql.org/wiki/Troubleshooting_Installation
For follow-ups to the mailing list please read:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Well, in my case nothing worked, and disabling McAffee needed a special ticket with my company's security team to actually do... so I installed using the binaries, by following this guide Helpful Guide.
In summary, download the binary from here, unzip it, go inside the pgsql folder, create log and data directories in there, and then open a command prompt, navigate to where the pgsql\bin folder is, and run initdb -U postgres -A password -E utf8 -W -D POSTGRESQL_ROOT\data
You can start and stop the server by running
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" start
and
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" stop
where POSTGRESQL_ROOT is the full path to the pgsql folder.
All the above did not work for me. I was getting an error like:
Script output:
CScript Error: Windows Script Host access is disabled on this machine. Contact your administrator for details.
so after a couple of googling i found the solution:
Navigate to the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings
In the right panel, you will see Enabled. If you see the entry 0, it means that the Windows Script Host access is disabled on your Windows machine.
Double Click on it and give it Value Data 1 to enable it.
A value of 1 will enable Windows Script Host
A value of 0 will disable Windows Script Host.
for windows 10 navigate to
HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings
To prevent further problems you should also exclude the data directory (where Postgres puts its data) from being scanned by your virus-scanner
In my case it was another application that caused the problem. Not Notepad++. To others who encounter this problem, you can diagnose it by first deleting all files in C:\Documents and Settings\UserName\Local Settings\Temp so that you'll be able to find the bitrock_installer.log easily when you try installing postgresql again and view the instructions in it. Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it.
I had this issue when trying to install the 32 bit version on Windows 7 64 bit.
Trying the install kit for 64 bit presented no errors, but the solutions presented by others are also valid.
In my case I've downloded McAfee removal tool
MCPR (McAfee Consumer Product Removal)
which cleaned up some tailings after McAfee uninstallation.
Some registry entries which previously had InprocServer32 values like 'c:\program files\common files\mcafee\systemcore\...' changed back to its original values:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = C:\Windows\SysWow64\vbscript.dll
After that I successfully installed PostgreSQL 9.3
it happens when Notepad++ associates .vbs file types.
you can open notepad++ -> Preferences -> fileAssociation
Remove the .vbs from the registered exts.
Close the notepad++. Try installing Postgres again.
In my case Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it. BlueFish is grab .vbs file association.
In the temp directory, my bitrock_installer.log file had the following:
Executing cscript //NoLogo "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs"
Script exit code: 1
Script output:
Input Error: Can not find script file "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs".
Turns out that Windows has a symlink between the following directories:
C:\Users\cpetrie\Local Settings\Temp
C:\Users\cpetrie\AppData\Local\Temp
For some reason my "TMP" and "TEMP" user variables were referencing the "Local Settings" path instead of the "AppData" path. Changing this fixed my install issue.
My problem was Smad-Av which disables Windows Scripts from running,
Only after going through this thread i remembered.
I just right clicked the Smad-Av icon and selected Allow Windows-Script & Office-Macro (Permanent).
I had the same problem with installing PostgreSQL (Unable to write in TEMP environment variable path), the problem was in Windows Script Host which was disabled (check the log file to see if this is your problem). enable it with register editor (run-->regedit) at this location Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings by setting its value at 1
For more details check this web link: http://1stopit.blogspot.com/2011/01/postgresql-83-and-84-fails-to-install.html
I had the same problem in Windows 10 and the culprit was the OS's permission, or rather the lack thereof, on allowing the executable to write on the User dedicated Temp folder.
Solved it by following my gut and changing the User Temp folder to the same with the system's : Win + Pause/Break to have the Computer Properties window appear (you can do that manually by right-click on Computer icon on Desktop -> Properties) -> click on Advanced System Settings on the panel on the left -> click on Environment Variables and
under "System variables" - Variables, find the TEMP and TMP ones and copy their paths. Then, under "User variables for Administrator" - Variables, find the TEMP and TMP ones and paste the paths. It's most always "C:\Windows\TEMP" anyways ;)
There's this site I read : https://www.askvg.com/where-does-windows-store-temporary-files-and-how-to-change-temp-folder-location/
search for "Registery Editor" and run it.
choose HKEY_CURRENT_USER => SOFTWARE => Microsoft => Windows script host => Setting (Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Script Host\Settings)
open "Enabled" and change value data to "1".(you will find it with a vlaue of 0).
Happy coding!
Check the log in the system's TEMP directory (provided the installer is able to write into it).
There's lot of information about the errors.
My issue was that VBS files were associated with a text editor (probably the anti virus software is the culprit) .
Here you can find some reg edit scripts to revert to the default behaviour:
http://www.nilpo.com/2009/07/windows-xp/restoring-vbs-vbscript-script-file-file-associations/#more-107
Cheers
My solution is similiar to #5, with an Explantion of how and why McAfee ruins your vbscript registration.
Apparently, when I had McAfee antivirus software on my computer, it bashed the vbscript.dll registration that Windows Scripting Host needs to run .VBS files.
In the exported .REG file:
[HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
#="C:\Program Files\Common Files\McAfee\SystemCore\ScriptSn.20120327211246.dll"
That SHOULD be changed back to "C:\Windows\System32\vbscript.dll" now.
McAfee apparently installs a DLL that hijacks the vbscript.dll in order to try to protect bad scripts from running. When I uninstalled McAfee in favor of Microsoft
Security Essentials, McAfee did not restore the registry paths ("not
my problem"), and the McAfee DLL, of course, was removed from the location during uninstall, so the vbscript.dll registration in fact pointed to NOWHERE and NOTHING.
There has to be a better way to write Antivirus software so that it doesn't disable the user's operating system when it is uninstalled, or when features
are turned off, or replace registration. See the following:
https://kc.mcafee.com/corporate/index?page=content&id=KB71660
I have a 64-bit OS. The registry path was changed in a number of locations.
The regular class ID should point to the "C:\Windows\System32\vbscript.dll" 64-bit file.
The "Wow6432Node" registry paths should point to the "C:\Windows\SysWOW64\vbscript.dll" 32-bit file.
Yes, the 64-bits are in the "32" folder and the 32-bits are in the "SysWOW64" folder. Microsoft didn't want to change the name of the main "System32" execution folder when it migrated to 64-bits.
HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_CLASSES_ROOT\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
Before you start messing with the registry, check if WSH is actually disabled or not. To do that run wscript.exe in the DOS box.
If you see a dialog box called "Windows Script Host Settings", WSH is enabled, and your problem with PostgreSQL installation must be related to something else.
If you get an error box that says "Windows Script Host access is disabled on this machine. Contact your administrator for details", WSH is disabled, and your problem with PostgreSQL installation may be related to it (or may be not).
For me, my problem was related to Windows script. I resolved this by right-clicking on smadav icon in the hidden icons in the task bar and checked "Allow Windows-script and Office-Macro (Permanent)". Then double click on the PostgreSQL setup again.
First go to registry Editor then choose HKEY_CURRENT_USER > software > Microsoft > Windows script host > setting > default > add value data to 1 and click Ok. done!
After disabling Smad Av, it still did not work. So, I right clicked on the Smad Av tray icon and I selected 'Allow Windows-Script & Office-Macro (Permanent)' and it worked.

Resources