I have two .reg files, the difference between them is only in Key which depends on the version of Windows.
My registry file for Windows x86:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\NGG]
#="URL:NGG Protocol"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\NGG\DefaultIcon]
#="C:\\wpf.exe"
"Test"="ika"
[HKEY_CLASSES_ROOT\NGG\Shell]
[HKEY_CLASSES_ROOT\NGG\Shell\Open]
[HKEY_CLASSES_ROOT\NGG\Shell\Open\command]
#="\"C:\\Program Files\\NGG\\start.exe\" \"%1\""
The difference in Windows x64:
#="\"C:\\Program Files(x86)\\NGG\\start.exe\" \"%1\""
How can I make an install script (InstallShield MSI) which checks the Windows version and then uses this current registry file.
Please help.
I would avoid using .reg files for this. Instead use InstallShield's and/or Windows Installer's support for variable values in the registry, and specify either "[ProgramFilesFolder]NGG\start.exe" "%1" in an MSI-based installation or "<PROGRAMFILES>\NGG\start.exe" "%1" in InstallScript based installation as the value in the Registry view.
(Or possibly go even more specific by using Verb support in an MSI-based project. Or reference something like "[#start.exe]" "%1" for your path, assuming you install that executable with a filekey of start.exe - see Formatted for details.)
Related
When I was working in versions of windows prior to Windows 10, I was able to get the debugger to be invoked when a particular executable was started. To do this I created the following batch file:
#echo off
>%temp%\output.reg echo Windows Registry Editor Version 5.00
>>%temp%\output.reg echo+
>>%temp%\output.reg echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\regsvr32.exe]
>>%temp%\output.reg echo "debugger"="vsjitdebugger.exe"
regedit /s %temp%\output.reg
del %temp\output.reg
And to stop it I used:
#echo off
>%temp%\output.reg echo Windows Registry Editor Version 5.00
>>%temp%\output.reg echo+
>>%temp%\output.reg echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\regsvr32.exe]
>>%temp%\output.reg echo "debugger"=-
regedit /s %temp%\output.reg
del %temp\output.reg
Of course these files are used exclusively for regsvr32.exe. I have others for other executables.
However, when using this trick under Windows 10, it failed to work. I would get the error:
An error occurred while launching 'regsvr32 "my.dll"':
The Visual Studio Just-In-Time Debugger was not notified that the application correctly started.
Check the documentation index for 'Just-in-time debugging, errors' for more information.
I don't know what documentation index that it was referring to, but I figured that it was some permission issue, so I tried to change the settings on the vsjitdebugger.exe file to Run this program as an administrator, to which I got a different error dialog that said:
C:\WINDOWS\system32\regsvr32.exe
The requested operation requires elevation.
Now, if I were to open up a Administrator cmd window and use the command:
vsjitdebugger.exe regsvr32 "my.dll"
This does invoke the debugger at start up of the regsvr32.exe application. However, the point of this trick was to ensure that the debugger gets invoked when anything executes the application, which may not be under a cmd process that I am controlling.
So I have 2 questions.
Does anyone know of the document index that is being referred to in the error message?
How do I get this to work under Windows 10 Version 1709 (OS Build 16299.371)?
I had the same issue. No idea why, but apparently on Windows 10 it's necessary to configure something in the registry, which as far as I remember wasn't necessary before, or maybe happened automatically when installing Visual Studio.
It's mentioned here under "troubleshooting": https://learn.microsoft.com/en-us/visualstudio/debugger/debug-using-the-just-in-time-debugger#jit_errors
The fix is to add a DWORD Value of Auto, with Value data of 1, to the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
(For 64-bit machines): HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
I have Windows 7, 64-bit.
I'm trying to register a .dll (comdlg32.dll) using regsvr32. But I get an error that says the dll is read but the DLLRegistryServer entry point is not found.
I have run the command under both System32 and SysWOW64 and I have run my commands with "Run As Administrator".
My old MSComDlg.CommonDialog component is no longer working with 64-bit.
comdlg32.dll is not a COM DLL and cannot be registered.
One way to confirm this for yourself is to run this command:
dumpbin /exports comdlg32.dll
You'll see that comdlg32.dll doesn't contain a DllRegisterServer method. Hence RegSvr32.exe won't work.
That's your answer.
ComDlg32.dll is a a system component. (exists in both c:\windows\system32 and c:\windows\syswow64) Trying to replace it or override any registration with an older version could corrupt the rest of Windows.
I can help more, but I need to know what MSComDlg.CommonDialog is. What does it do and how is it supposed to work? And what version of ComDlg32.dll are you trying to register (and where did you get it)?
comdlg32.dll is not really a COM dll (you can't register it).
What you need is comdlg32.ocx which contains the MSComDlg.CommonDialog COM class (and indeed relies on comdlg32.dll to work). Once you get ahold on a comdlg32.ocx, then you will be able to do regsvr32 comdlg32.ocx.
Registering DLL for Fundsite
Outdated or missing comdlg32.ocx runtime library can be the problem of causing this error.
Make sure comdlg32.ocx file is not corrupted otherwise Download the File comdlg32.ocx (~60 Kb Zip).
Download the file and extract the comdlg32.ocx to your the Windows\System32 folder or Windows\SysWOW64. In my case i started with Windows\System32 but it didn’t work at my end, so I again saved in Windows\SysWOW64.
Type following command from Start, Run dialog:“c:\windows>System32\regsvr32 Comdlg32.ocx “ or “c:\windows>SysWOW64\regsvr32 Comdlg32.ocx ”
Now Comdlg.ocx File is register and next step is to register the DLL
Copy the Fundsite.Text.Encoding. dll into .Net Framework folder for 64bit on below path
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
Then on command prompt and go to directory C:\Windows\Microsoft.NET\Framework64\v2.0.50727 and then run the following command as shown below.
This will register the dll successfully.
C:\Windows\Microsoft.net\framework64\v2.0.50727>regasm "Dll Name".dll
Have you unistalled your Internet Explorer?
I did, and I had the same issues, if so, you have to:
Reactivate IE (Control Panel -- Programs and Features -- Turn Windows features on or off).
restarting the computer
(important!) running Windows Update to get all available updates for Microsoft Explorer
restarting the computer (again)
Finally it works!
I have faced the same issue with COMDLG32.OCX and MSFLXGRD.OCX in Windows 10 and Visual Studio 2010. It's an MFC application.
Then I downloaded its zip file from the google after extracting copy them at following paths:
C:\Windows\System32 (*For 32-bit machine*)
C:\Windows\SysWOW64 (*For 64-bit machine*)
Then run Command Prompt as an Administrator then run the following commands:
For Windows 64-bit systems c:\windows\SysWOW64\ regsvr32 comdlg32.ocx
c:\windows\SysWOW64\regsvr32 msflxgrd.ocx (My machine is 64-bit configuration)
For Windows 32-bit systems c:\windows\System32\ regsvr32 comdlg32.ocx
c:\windows\System32\regsvr32 msflxgrd.ocx
On successfully updation of the above cmds it shows succeed message.
Information about missing entry point error installing legacy VB6 compiled applications on Windows 10 which I hope could be useful to someone.
Missing OCX files can be found in the "OS\System folder" of the Visual Basic 6.0 installer package.
Today I copied the relevant OCX file (from our network) to the local computer
And then I typed the commands below, as administrator, which normally work to register it.
cd \windows\syswow64
regsvr32.exe /u mscomctl.ocx
regsvr32.exe /i mscomctl.ocx
(add the path to the locally copied file for the /i command)
However today I got errors from both these regsvr32.exe commands.
The second error was giving the DllImport missing entry point error which is similar to the error mentioned by the original poster.
To resolve, one of the things I tried was leaving out the switch -
regsvr32.exe mscomctl.ocx
To my surprise it then said it was successful.
To confirm, the application started up properly afterwards.
SOLUTION OF Regsvr32: DllRegisterServer entry point was not found,
Go to systemdrive(generally c:)\system32 and search file "Regsvr32.exe"
Right click and click in properties and go to security tab and click in advanced button.
Click in owner tab and click edit and select administrators and click ok.
Click in permissions
Click in change permissions.
Choose administrators and click edit and put tick on full control and click ok.
Similarly, choose SYSTEM and edit and put tick on full control and click ok and click in other dialog box which are opened.
Now .dll files can be registered and error don't come, you should re-install any software whose dll files was not registered during installation.
I also had the similar problem while registering myinfo.dll file in windows 7. Following work for me:
Create a short cut on your desktop
C:\Windows\System32\regsvr32.exe c:\windows\system32\myinfo.dll
right click on the short cut just created and select as Run as administrator.
I have troubles with .vsix installation.
If I launch the .vsix from the explorer, instead of suggesting me to install the package, I get the same ouput as Vsixintaller.exe /? (it displays the command line usage).
I also tried to run the following command line :
VSIXInstaller.exe /skuname:Pro "fullpathto\NuGet.Tools.vsix"
Same output (command line usage is displayed).
What can be wrong ?
I'm suspecting a wrong registry registration, but I couldn't find the source of the problem.
Here is what I have in my registry :
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\VisualStudio.Launcher.vsix] #="Microsoft Visual
Studio Extension"
[HKEY_CLASSES_ROOT\VisualStudio.Launcher.vsix\DefaultIcon]
#="C:\Program Files (x86)\Common Files\Microsoft
Shared\MSEnv\VSFileHandler.dll,-221"
[HKEY_CLASSES_ROOT\VisualStudio.Launcher.vsix\Shell]
[HKEY_CLASSES_ROOT\VisualStudio.Launcher.vsix\Shell\Open]
[HKEY_CLASSES_ROOT\VisualStudio.Launcher.vsix\Shell\Open\Command]
#="\"C:\Program Files (x86)\Common Files\Microsoft
Shared\MSEnv\VSLauncher.exe\" \"%1\""
[HKEY_CLASSES_ROOT.vsix] "Content Type"="application/vsix"
#="VisualStudio.Launcher.vsix"
[HKEY_CLASSES_ROOT.vsix\OpenWithProgids]
"VisualStudio.Launcher.vsix"=""
Any idea ?
PS: my computer is running W2K8 R2 x64, and I use VS 2010 Pro.
I cannot use Visual Studio integrated extension manager because of a proxy server not working with the gallery (don't know why)
Oh ... finally found the issue.
VSix Installer does not seems to be able to install from a network share.
With local copies of vsix, it worked. Strange.
I created installer via NSIS. "c:\program files\myapp" is default folder for my application. But I need another default folder (for example c:\users\\AppData\myapp) in Windows Vista.
I found lot of Functions to determine Windows version, but I cannot call them before defining InstallDir variable. Any ideas how to do it?
You can set $instdir in .OnInit, or use MultiUser.nsh
I want to extract the MSI of an EXE setup to publish over a network.
For example, using Universal Extractor, but it doesn't work for Java Runtime Environment.
For InstallShield MSI based projects I have found the following to work:
setup.exe /s /x /b"C:\FolderInWhichMSIWillBeExtracted" /v"/qn"
This command will lead to an extracted MSI in a directory you can freely specify and a silently failed uninstall of the product.
The command line basically tells the setup.exe to attempt to uninstall the product (/x) and do so silently (/s). While doing that it should extract the MSI to a specific location (/b).
The /v command passes arguments to Windows Installer, in this case the /qn argument. The /qn argument disables any GUI output of the installer.
Quick List: There are a number of common types of setup.exe files. Here are some of them in a "short-list". More fleshed-out details here
(towards bottom).
Setup.exe Extract: (various flavors to try)
setup.exe /a
setup.exe /s /extract_all
setup.exe /s /extract_all:[path]
setup.exe /stage_only
setup.exe /extract "C:\My work"
setup.exe /x
setup.exe /x [path]
setup.exe /s /x /b"C:\FolderInWhichMSIWillBeExtracted" /v"/qn"
dark.exe -x outputfolder setup.exe
dark.exe is a WiX binary - install WiX to extract a WiX setup.exe (as of now). More (section 4).
There is always:
setup.exe /?
Temp Folder: And the last resort: launch the installer and then look for extracted files in the temp folder (more details below).
Real-world, pragmatic Installshield setup.exe extraction.
Installshield: Setup.exe and Update.exe Command-Line Parameters.
Installshield setup.exe commands (sample)
Wise setup.exe commands
Advanced Installer setup.exe commands.
MSI Extract: msiexec.exe / File.msi extraction:
msiexec /a File.msi
msiexec /a File.msi TARGETDIR=C:\MyInstallPoint /qn
msiexec.exe command lines.
Microsoft's msiexec.exe documentation on MSDN.
Many Setup Tools: It is impossible to cover all the different kinds of possible setup.exe files. They might feature all kinds of different command line switches. There are so many possible tools that can be used. (non-MSI,MSI, admin-tools, multi-platform, etc...).
NSIS / Inno: Commmon, free tools such as Inno Setup seem to make extraction hard (unofficial unpacker, not tried by me, run by virustotal.com). Whereas NSIS seems to use regular archives that standard archive software (7-zip et al) can open and extract.
General Tricks: One trick is to launch the setup.exe and look in the 1) system's temp folder for extracted files.
Another trick is to use 2) 7-Zip, WinRAR, WinZip or similar
archive tools to see if they can read the format. Some claim success
by 3) opening the setup.exe in Visual Studio. Not a technique
I use. 4) And there is obviously application repackaging -
capturing the changes done to a computer after a setup has run and
clean it up - requires a special tool (most of the free ones
come and go, Advanced Installer Architect and AdminStudio are big
players).
UPDATE: A quick presentation of various deployment tools used to create
installers:
How to create windows installer (comprehensive links).
And a simpler list view of the most used development tools as of now (2018), for quicker reading and overview.
And for safekeeping:
Create MSI from extracted setup files (towards bottom)
Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file (different kinds of Installshield setup.exe files)
What is the purpose of administrative installation initiated using msiexec /a?.
Just a disclaimer: A setup.exe file can contain an embedded MSI, it can be a legacy style (non-MSI) installer or it can be just a regular executable with no means of extraction whatsoever. The "discussion" below first presents the use of admin images for MSI files and how to extract MSI files from setup.exe files. Then it provides some links to handle other types of setup.exe files. Also see the comments section.
UPDATE: a few sections have now been added directly below, before the description of MSI file extract using administrative installation. Most significantly a blurb about extracting WiX setup.exe bundles (new kid on the block). Remember that a "last resort" to find extracted setup files, is to launch the installer and then look for extracted files in the temp folder (Hold down Windows Key, tap R, type %temp% or %tmp% and hit Enter) - try the other options first though - for reliability reasons.
Apologies for the "generalized mess" with all this heavy inter-linking. I do believe that you will find what you need if you dig enough in the links, but the content should really be cleaned up and organized better.
General links:
General links for handling different kinds of setup.exe files (towards bottom).
Uninstall and Install App on my Computer silently (generic, but focus on silent uninstall).
Similar description of setup.exe files (link for safekeeping - see links to deployment tools).
A description of different flavors of Installshield setup.exe files (extraction, silent running, etc...)
Wise setup.exe switches (Wise is no longer on the market, but many setup.exe files remain).
Extract content:
Extract WiX Burn-built setup.exe (a bit down the page) - also see section directly below.
Programmatically extract contents of InstallShield setup.exe (Installshield).
Vendor links:
Advanced Installer setup.exe files.
Installshield setup.exe files.
Installshield suite setup.exe files.
WiX Toolkit & Burn Bundles (setup.exe files)
Tech Note: The WiX toolkit now delivers setup.exe files built with the bootstrapper tool Burn that you need the toolkit's own dark.exe decompiler to extract. Burn is used to build setup.exe files that can install several embedded MSI or executables in a specified sequence. Here is a sample extraction command:
dark.exe -x outputfolder MySetup.exe
Before you can run such an extraction, some prerequisite steps are required:
Download and install the WiX toolkit (linking to a previous answer with some extra context information on WiX - as well as the download link).
After installing WiX, just open a command prompt, CD to the folder where the setup.exe resides. Then specify the above command and press Enter
The output folder will contain a couple of sub-folders containing both extracted MSI and EXE files and manifests and resource file for the Burn GUI (if any existed in the setup.exe file in the first place of course).
You can now, in turn, extract the contents of the extracted MSI files (or EXE files). For an MSI that would mean running an admin install - as described below.
There is built-in MSI support for file extraction (admin install)
MSI or Windows Installer has built-in support for this - the extraction of files from an MSI file. This is called an administrative installation. It is basically intended as a way to create a network installation point from which the install can be run on many target computers. This ensures that the source files are always available for any repair operations.
Note that running an admin install versus using a zip tool to extract the files is very different! The latter will not adjust the media layout of the media table so that the package is set to use external source files - which is the correct way. Always prefer to run the actual admin install over any hacky zip extractions. As to compression, there are actually three different compression algorithms used for the cab files inside the MSI file format: MSZip, LZX, and Storing (uncompressed). All of these are handled correctly by doing an admin install.
Important:
Windows Installer caches installed MSI files on the system for repair, modify and uninstall scenarios. Starting with Windows 7 (MSI version 5) the MSI files are now cached full size to avoid breaking the file signature that prevents the UAC prompt on setup launch (a known Vista problem). This may cause a tremendous increase in disk space consumption (several gigabytes for some systems). To prevent caching a huge MSI file, you should run an admin-install of the package before installing. This is how a company with proper deployment in a managed network would do things, and it will strip out the cab files and make a network install point with a small MSI file and files besides it.
Admin-installs have many uses
It is recommended to read more about admin-installs since it is a useful concept, and I have written a post on stackoverflow: What is the purpose of administrative installation initiated using msiexec /a?.
In essence the admin install is important for:
Extracting and inspecting the installer files
To get an idea of what is actually being installed and where
To ensure that the files look trustworthy and secure (no viruses - malware and viruses can still hide inside the MSI file though)
Deployment via systems management software (for example SCCM)
Corporate application repackaging
Repair, modify and self-repair operations
Patching & upgrades
MSI advertisement (among other details this involves the "run from source" feature where you can run directly from a network share and you only install shortcuts and registry data)
A number of other smaller details
Please read the stackoverflow post linked above for more details. It is quite an important concept for system administrators, application packagers, setup developers, release managers, and even the average user to see what they are installing etc...
Admin-install, practical how-to
You can perform an admin-install in a few different ways depending on how the installer is delivered. Essentially it is either delivered as an MSI file or wrapped in an setup.exe file.
Run these commands from an elevated command prompt, and follow the instructions in the GUI for the interactive command lines:
MSI files:
msiexec /a File.msi
that's to run with GUI, you can do it silently too:
msiexec /a File.msi TARGETDIR=C:\MyInstallPoint /qn
setup.exe files:
setup.exe /a
A setup.exe file can also be a legacy style setup (non-MSI) or the dreaded Installscript MSI file type - a well known buggy Installshield project type with hybrid non-standards-compliant MSI format. It is essentially an MSI with a custom, more advanced GUI, but it is also full of bugs.
For legacy setup.exe files the /a will do nothing, but you can try the /extract_all:[path] switch as explained in this pdf. It is a good reference for silent installation and other things as well. Another resource is this list of Installshield setup.exe command line parameters.
MSI patch files (*.MSP) can be applied to an admin image to properly extract its files. 7Zip will also be able to extract the files, but they will not be properly formatted.
Finally - the last resort - if no other way works, you can get hold of extracted setup files by cleaning out the temp folder on your system, launch the setup.exe interactively and then wait for the first dialog to show up. In most cases the installer will have extracted a bunch of files to a temp folder. Sometimes the files are plain, other times in CAB format, but Winzip, 7Zip or even Universal Extractor (haven't tested this product) - may be able to open these.
7-Zip should do the trick.
With it, you can extract all the files inside the EXE (thus, also an MSI file).
Although you can do it with 7-Zip, the better way is the administrative installation as pointed out by Stein Åsmul.
I'm guessing this question was mainly about InstallShield given the tags, but in case anyone comes here with the same problem for WiX-based packages (and possibly others), just call the installer with /extract, like so:
C:\> installer.exe /extract
That'll place the MSI in the folder alongside the installer.
Starting with parameter:
setup.exe /A
asks for saving included files (including MSI).
This may depend on the software which created the setup.exe.
The only way to do that is running the exe and collect the MSI. The thing you must take care of is that if you are tranforming the MSI using MST they might get lost.
I use this batch commandline:
SET TMP=c:\msipath
MD "%TMP%"
SET TEMP=%TMP%
start /d "c:\install" install.exe /L1033
PING 1.1.1.1 -n 1 -w 10000 >NUL
for /R "%TMP%" %%f in (*.msi) do copy "%%f" "%TMP%"
taskkill /F /IM msiexec.exe /T
Launch the installer, but don't press the Install > button. Then
cd "%AppData%\..\LocalLow\Sun\Java"
and find your MSI file in one of sub-directories (e.g., jre1.7.0_25).
Note that Data1.cab from that sub-directory will be required as well.
There is no need to use any tool !! We can follow the simple way.
I do not know which tool built your self-extracting Setup program and so, I will have to provide a general response.
Most programs of this nature extract the package file (.msi) into the TEMP directory. This behavior is the default behavior of InstallShield Developer.
Without additional information, I would recommend that you simply launch the setup and once the first MSI dialog is displayed, you can examine your TEMP directory for a newly created sub-directory or MSI file. Before cancelling/stopping an installer just copy that MSI file from TEMP folder. After that you can cancel the installation.