I am doing an installer and I have an issue when it gets uninstalled that Windows will throw an error (even if run using regsrv32 /u so essentially I want to add the /s flag to the RegDll "$SYSDIR\foo32.dll" in the NSIS script.
I also assume that $SysDir will be windows\syswow64 on 64-bit systems, and system32 on 32-bit? it is a 32-bit driver that exists in the system path.
Thanks
I'm a bit confused because you are talking about RegDLL and regsrv32.exe and they are different things! RegDLL can never use a /s switch because the functions it calls do not have a silent parameter.
RegDLL and UnRegDLL are NSIS instructions and internally they call LoadLibrary+GetProcAddress for DllRegisterServer and DllUnregisterServer respectively and never uses regsrv32.exe. They never display any message dialogs but they do print some text to the log on the instfiles page and you can control this with SetDetailsPrint. The registration functions in your libraries might display a messagebox but there is nothing NSIS can do about that.
NSIS also ships with a header file called Library.nsh and it contains more advanced control over how things are registered and it might call out to "$SYSDIR\regsvr32.exe" for 64-bit libraries but it always uses the /s switch. When using Library.nsh you must set the correct defines if you are also installing 64-bit libraries!
If you are always installing just a 32-bit library it might look something like this:
!include Library.nsh
Section Uninstall
!insertmacro UnInstallLib REGDLL NOTSHARED REBOOT_NOTPROTECTED "$InstDir\whatever.dll"
SectionEnd
If you have 32 and 64-bit libraries it might look something like this:
!include Library.nsh
!include x64.nsh
Section Uninstall
!insertmacro UnInstallLib REGDLL NOTSHARED REBOOT_NOTPROTECTED "$InstDir\whatever-32.dll"
${If} ${RunningX64}
!define LIBRARY_X64
!insertmacro UnInstallLib REGDLL NOTSHARED REBOOT_NOTPROTECTED "$InstDir\whatever-64.dll"
!undef LIBRARY_X64
${EndIf}
SectionEnd
Related
Is it possible to initiate a silent installation of a WiX bundle through the use of a command line argument in the format of /a or /arg?
I'm aware of the available command line arguments accepted by the wixstdba bootstrapper.
Specifically, we need to do this using the argument /s /v/qn argument.
NB: Executing the bootsrapper with the command line setup.exe /s /v/qn actually does initiate a silent install, and I assume this is because the BA interprets the /s as equivalent to -s. But since I can't find this behaviour documented anywhere, I am nervous about relying upon it, and would prefer an explicit method for doing this.
TL;DR
The reason we would like to support this argument /format is due to the automatic upgrade operation of a previous version of the software. This version of the software launched an automatically downloaded upgrade to itself, which was an InstallShield package, with the switches /s /v/qn to launch the MSI as a silent installation. Those switches are coded into a constant field, so the fact that we are moving from InstallShield to WiX presents this problem.
We would like to replicate this functionality but need a way to translate this set of arguments to either a -silent or -passive argument, or find some other method to accomplish this task.
Burn supports both - and / as switch characters. Silent UI mode is supported as q, quiet, s, and silent with leading - and /. See the code at https://github.com/wixtoolset/wix3/blob/develop/src/burn/engine/core.cpp#L1098.
I have an .MSI installer that I created using WIX and works fine when opening the file from windows explorer or installing from a command window using msiexec /i. The problem is that I need to use /a to install it using a group policy when the computer turns on.
When using the /i option the ProgramFilesFolder value is set correctly to "C:\Program Files (x86)\".
When using the /a option the value of ProgramFilesFolder is set to "C:\", and then I get an error (on the Log) that says:
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2203. The arguments are: C:\Referrals.msi, -2147287035,
Note: I am not running the .MSI file from "C:\"
Try
msiexec /a TARGETDIR="c:\temp\location" /passive
I think you may have the msiexec.exe command line mixed up: /a is admin install. This is essentially a command to create a network installation point with extracted files to use for installation on a lot of computers. This ensures the source files are available for patching, self-repair, repair, reinstall, etc...
To deal with advertisement and group policy you need to use these command line options. So a very basic operation would be advertise product to all users silently and write a log file:
msiexec.exe /JM "Installer.msi" /QN /L* "C:\msilog.log"
I've made a mistake in IDL file by increasing library version. After that I revert the version. Since the time I can't work with library, because VB6 still write : "There is new version of library * Do you want to upgrade to version 3.0" ....
in OLE/COM Object viewer I've seen registred some version of my library. Exist some way how to unregister these type library? I try to erase DLL and TLB files from computer, erase all keys from Windows registers ... But "Visual Basic 6" and "OLE/COM Object viewer" still have information about it.
Thx
Run regsvr32 /u Something.DLL to remove the DLL from the COM registration.
Use regsvr32 /u <path to file> from an elevated command prompt.
You need to unregister the DLL/TLB that contains the invalid version, otherwise the registry will still contain references to your 'mistake'. If you don't have the file any ore: increase the library version, recompile, and unregister.
This worked for me (lucky guess)
regasm.exe /unregister /tlb my.dll
I have tried to use the following code:
cd c:\windows\system32
regsvr32.exe dllname.ax
But this is not working for me. How can I register a DLL file on Windows 7 with a 64-bit processor?
Well, you don't specify if it's a 32 or 64 bit dll and you don't include the error message, but I'll guess that it's the same issue as described in this KB article: Error Message When You Run Regsvr32.exe on 64-Bit Windows
Quote from that article:
This behavior occurs because the Regsvr32.exe file in the System32
folder is a 64-bit version. When you run Regsvr32 to register a DLL,
you are using the 64-bit version by default.
Solution from that article:
To resolve this issue, run Regsvr32.exe from the %SystemRoot%\Syswow64
folder. For example, type the following commands to register the DLL:
cd \windows\syswow64 regsvr32 c:\filename.dll
If the DLL is 32 bit:
Copy the DLL to C:\Windows\SysWoW64\
In an elevated command prompt: %windir%\SysWoW64\regsvr32.exe %windir%\SysWoW64\namedll.dll
if the DLL is 64 bit:
Copy the DLL to C:\Windows\System32\
In an elevated command prompt: %windir%\System32\regsvr32.exe %windir%\System32\namedll.dll
I know it seems the wrong way round, but that's the way it works. See:
http://support.microsoft.com/kb/249873
Quote: "Note On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
"
Type regsvr32 name.dll into the Command Prompt (executed in elevated mode!) and press "Enter." Note that name.dll should be replaced with the name of the DLL that you want to register. For example, if you want to register the iexplore.dll, type regsvr32 iexplore.dll.
On a x64 system, system32 is for 64 bit and syswow64 is for 32 bit (not the other way around as stated in another answer). WOW (Windows on Windows) is the 32 bit subsystem that runs under the 64 bit subsystem).
It's a mess in naming terms, and serves only to confuse, but that's the way it is.
Again ...
syswow64 is 32 bit, NOT 64 bit.
system32 is 64 bit, NOT 32 bit.
There is a regsrv32 in each of these directories. One is 64 bit, and the other is 32 bit.
It is the same deal with odbcad32 and et al. (If you want to see 32-bit ODBC drivers which won't show up with the default odbcad32 in system32 which is 64-bit.)
Open the start menu and type cmd into the search box Hold Ctrl + Shift and press Enter
This runs the Command Prompt in Administrator mode.
Now type: regsvr32 MyComobject.dll
If the DLL is 32 bit:
Copy the DLL to C:\Windows\SysWoW64\
In elevated cmd: %windir%\SysWoW64\regsvr32.exe %windir%\SysWoW64\namedll.dll
if the DLL is 64 bit:
Copy the DLL to C:\Windows\System32\
In elevated cmd: %windir%\System32\regsvr32.exe %windir%\System32\namedll.dll
Finally I found the solution just run CMD as administrator then write
cd \windows\syswow64
then write this
regsvr32 c:\filename.dll
I hope that answer will help you
Everything here was failing as wrong path. Then I remembered a trick from the old Win95 days. Open the program folder where the .dll resides, open C:/Windows/System32 scroll down to regsvr32 and drag and drop the dll from the program folder onto rgsrver32. Boom,done.
And while doing this, if you get error code 0x80040201, try the solution in DllRegisterServer failed with the error code 0x80040201, but make sure, you open command prompt as Run as Administrator.
Knowing the error message would be rather valuable. It is meant to provide info, even though it doesn't make any sense to you it does to us. Being forced to guess, I'd say that the DLL is a 32-bit DirectX filter. In which case this should be the proper course of action:
cd c:\windows\syswow64
move ..\system32\dllname.ax .
regsvr32.exe dllname.ax
This must be run at an elevated command prompt so that UAC cannot stop the registry access that's required. Ask more questions about this at superuser.com
I just tested this extremely simple method and it works perfectly--but I use the built-in Administrator account, so I don't have to jump through hoops for elevated privileges.
The following batch file relieves the user of the need to move files in/out of system folders. It also leaves it up to Windows to apply the proper version of Regsvr32.
INSTRUCTIONS:
In the folder that contains the library (-.dll or -.ax) file you wish to register, open a new text file and paste in ONE of the routines below :
echo BEGIN DRAG-AND-DROP %n1 REGISTRAR FOR 64-BIT SYSTEMS
copy %1 C:\Windows\System32
regsvr32 "%nx1"
echo END BATCH FILE
pause
echo BEGIN DRAG-AND-DROP %n1 REGISTRAR FOR 32-BIT SYSTEMS
copy %1 C:\Windows\SysWOW64
regsvr32 "%nx1"
echo END BATCH FILE
pause
Save your new text file as a batch (-.bat) file; then simply drag-and-drop your -.dll or -.ax file on top of the batch file.
If UAC doesn't give you the opportunity to run the batch file as an Administrator, you may need to manually elevate privileges (instructions are for Windows 7):
Right-click on the batch file;
Select Create shortcut;
Right-click on the shortcut;
Select Properties;
Click the Compatibility tab;
Check the box labeled Run this program as administrator;
Drag-and-drop your -.dll or -.ax file on top of the new shortcut instead of the batch file.
That's it. I chose COPY instead of MOVE to prevent the failure of any UAC-related follow-up attempt(s). Successful registration should be followed by deletion of the original library (-.dll or -.ax) file.
Don't worry about copies made to the system folder (C:\Windows\System32 or C:\Windows\SysWOW64) by previous passes--they will be overwritten every time you run the batch file.
Unless you ran the wrong batch file, in which case you will probably want to delete the copy made to the wrong system folder (C:\Windows\System32 or C:\Windows\SysWOW64) before running the proper batch file, ...or...
Help Windows choose the right library file to register by fully-qualifying its directory location.
From the right batch file copy the system folder path
If 64-bit: C:\Windows\System32
If 32-bit: C:\Windows\SysWOW64
Paste it on the next line so that it precedes %nx1
If 64-bit: regsvr32 "C:\Windows\System32\%nx1"
If 32-bit: regsvr32 "C:\Windows\SysWOW64\%nx1"
Paste path inside quotation marks
Insert backslash to separate %nx1 from system folder path
or ...
Run this shotgun batch file, which will (in order):
Perform cleanup of aborted registration processes
Reverse any registration process completed by your library file;
Delete any copies of your library file that have been saved to either system folder;
Pause to allow you to terminate the batch file at this point (and run another if you would like).
Attempt 64-Bit Installation on your library file
Copy your library file to C:\Windows\System32;
Register your library file as a 64-bit process;
Pause to allow you to terminate the batch file at this point.
Undo 64-Bit Installation
Reverse any registration of your library file as a 64-bit process;
Delete your library file from C:\Windows\System32;
Pause to allow you to terminate the batch file at this point (and run another if you would like).
Attempt 32-Bit Installation on your library file
Copy your library file to C:\Windows\SystemWOW64
Register your library file as a 32-bit process;
Pause to allow you to terminate the batch file at this point.
Delete original, unregistered copy of library file
There is a difference in Windows 7. Logging on as Administrator does not give the same rights as when running a program as Administrator.
Go to Start - All Programs - Accesories.
Right click on the Command window and select "Run as administrator"
Now register the dll normally via : regsrvr32 xxx.dll
You need run the cmd.exe in c:\windows\system32\ by administrator
Commands:
For unregistration *.dll files
regsvr32.exe /u C:\folder\folder\name.dll
For registration *.dll files
regsvr32.exe C:\folder\folder\name.dll
Part of the confusion regarding regsvr32 is that on 64-bit windows the name and path have not changed, but it now registers 64-bit DLLs. The 32-bit regsvr32 exists in SysWOW64, a name that appears to represent 64-bit applications. However the WOW64 in the name refers to Windows on Windows 64, or more explicity Windows 32-bit on Windows 64-bit. When you think of it this way the name makes sense even though it is confusing in this context.
I cannot find my original source on an MSDN blog but it is referenced in this Wikipedia article http://en.wikipedia.org/wiki/WoW64
Here is how I fixed this issue on a Win7 x64 machine:
1 - error message:
"CoCreateInstance() failed
Plkease check your registry entries
CLSID{F088EA74-2E87-11D3-B1F3-00C0F03C37D3} and make sure you are logged in as an administrator"
2 - fix procedure:
Start/type cmd/RightMouseClick on cmd.exe and choose to "Run as Administrator"
typed:
regsvr32 /s C:\Program Files\Autodesk\3ds Max Design 2015\atl.dll
regsvr32 /s C:\Program Files\Autodesk\3ds Max Design 2015\MAXComponents.dll
restart Win 7 and back in business again !
Hope this helps !
If I have a Windows executable, how can I find out which dlls it will load?
I'm just talking about which ones that will be loaded statically, not ones it might load dynamically with something like LoadLibrary.
dumpbin is a tool that comes with VC++.
To see what DLLs a program will import:
Open Visual Studio
Menu Item Tools | Visual Studio Command prompt
cd to folder containing executable
dumpbin /dependents whatever.exe
Dump of file whatever.exe
File Type: EXECUTABLE IMAGE
Image has the following dependencies:
AIOUSB.DLL
sqlite3.dll
wxmsw293u_core_vc_custom.dll
wxbase293u_vc_custom.dll
KERNEL32.dll
ole32.dll
OLEAUT32.dll
MSVCP90.dll
MSVCR90.dll
To see what functions (and DLLs) it will import, use
C:\> dumpbin /imports whatever.exe
There are utilities that will do this for you.
In the past I've used the MS tool (depends.exe) that came with (I think) VB.:
VS2010
VS2012
VS2013
VS2015
Current
and there's this as well:
http://dependencywalker.com/
and probably others as well.
Open the command prompt and then type below command
tasklist /m /fi "imagename eq netbeans.exe"
Type instead netbeans.exe whatever name your exe file name.
Dependency Walker can help you determine which .dll will be loaded.
Just go to the command prompt and type tasklist /m, you will see the list of dll files used by specific program.
Solution for Microsoft .Net:
foreach (AssemblyName a in Assembly.ReflectionOnlyLoadFrom("SAMPLE.EXE").GetReferencedAssemblies())
{
MessageBox.Show(a.Name);
}
There is a handy tool called NDepend that will give you all DLL dependencies.
progfr is simple and useful:
[http://members.fortunecity.com/michaelmoser/tip11.htm]
Dependencies - An open-source modern Dependency Walker shows which DLLs a Windows executable will load and it works well in modern Windows 10.
It is a little less powerful than Dependency Walker, but the latter may or may not work in Windows 10 as it was last updated in 2006. (Newer versions of Dependency Walker were bundled with some versions of Windows Development Kit for Windows 10, but not any more.)
Process Explorer
Comes with SysInternals Suite
https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite
Benefits: allows to explore the process that is already running (I have not found a was to attach the dependency walker to the existing process)