How do I register a DLL file on Windows 7 64-bit? - 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 !

Related

Racket error Failure: can not load the DLL

I send a Racket executable(in a distribution package) to a few friends and they get the error:"Failure: can not load the DLL". On my computer it runs without problems. It's using the rsound package.
Yes, good point. Currently, rsound is hard-coded to look in the collection path for the DLL. That won't work for programs compiled into executables. I've just updated rsound to tell it to look in "standard locations" as well for Windows and Mac.
Try this: Using the DrRacket package manager, update your copy of portaudio. When you're done, it should be at version "b9403a6dfbfb5eadf824ed91731ec141bf363677".
After this, it should be possible to pass along the executable file and run it, as long as the two required dll's are in the same directory as the executable. These two dll's are:
portaudio.dll
callbacks.dll
For windows, you'll find both of these in a subdirectory of the portaudio package. Finding these is going to be a teensy bit of a hassle on Windows; I believe these get installed in your user directory\RoamingData\\portaudio\lib\win32\x86_84\3m\ . If the target computer is a 32-bit machine, you'd substitute 'i386' for 'x86_64' in that path.
I know that Windows can make it quite hard to find the files you're looking for; let me know if you have any trouble.
Whew!

CMake-Configure: Permission Denied

I am trying to compile my Project with CMake, on one of my Computers it works perfectly (a Linux box), but the other one (Windows 7 Ultimate 64) has really problems.
I have tried multpiple generators:
MinGW (standalone and from CodeBlocks):
Error message:
(Just the part that should lead to a solution)
f:/tools/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe:
cannot open output file cmTryCompileExec.exe: Permission denied
collect2: ld returned 1 exit status
Visual Studio 10 Professional
Error Message:
(Again only the Part that may be interesting, i have translated it from german)
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "cl" is not able to compile a simple test program.
[...]
1>ClCompile:
1> testCCompiler.c
1>LINK : fatal error LNK1104: Datei
"H:\yps_2\VISUAL\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.exe" could not be opened.
I have Searched google and SO fpr days now and i think no one had some similar Problem like me...
I would be so glad if you could help me guys!
PS: There is another Issue on SO like mine, but it is unanswered:
https://stackoverflow.com/questions/7294011/permission-denied-errors-when-using-cmake
First make sure you're computer is not infected with viruses: If any viruses modifying EXE files exist, they can be the main cause you can't write to your own EXE files. Scan your computer with an up-to-date antivirus.
Another problem can be your anti-virus trying to block EXE hijacks. If you're sure your computer is clean, try fully disabling your antivirus.
Another solutions that come to my mind are:
Try right-clicking on Code Blocks or Visual Studio and choosing Run as Administrator.
If you are executing from Command Prompt, make sure you do it in an administrative Command Prompt.
Try putting the CMake and other related tools and also the output folder in your C:\ drive. Maybe you don't have quota or rights to access other drives?
Try disabling all services you see are useless. Maybe some service has just locked the file without using it for no good reason.
Try to dismount your H: volume and mount it again. (Either use diskmgmt.msc or use fsutil volume dismount H: and explore to mount it again)
Create the directory
H:\yps_2\VISUAL\CMakeFiles\CMakeTmp\Debug\
and make sure that you have write access.

MMC snap-in cannot locate a 3rd party DLL located in PATH directory

I am having a problem with a 32-bit MMC snap-ins (on a x64 server 2008 machine). The snap-ins have been successfully registered. When I launch the associated.msc file using the mmc (with 32 bit option), the name(s) of the snap-ins are displayed on the LHS but the RHS shows an error page that says the page could not be loaded.
Using procmon, I think that I have identified that the problem relates to the failure to locate a DLL that is also shipped with the product and used by the snap-in. This is located in a directory c:\\bin and this directory is specified in the PATH environment variable. However, the MMC seems to be looking only in the c:\windows\sysWOW6432 directory (i.e. the 32 bit version of the c:\windows\system32 on the 64 bit machine). I wouldn't mind this if it also went on to search the other directories specified on the PATH (which includes the c:\\bin directory).
I have tested this hypothesis and put the DLLs in the syswow6432 directory and things seem to work correctly from there on out.
I would obviously not want to put all the product specific DLLs in the system directory and would prefer to keep them within the product specific directory.
Can anyone explain the failure to locate the DLL on the PATH and a resolution.
Use the /codebase option of RegAsm.exe when registering your dependent assemblies. You can specify the fully-qualified path to your assembly which will be lazy-loaded when the snapin is selected from the MMC snapin tree.
On 64-bit MS operating systems, in the absence of /codebase, dependent assemblies/DLLs of 32-bit snapins are loaded from the SYSWOW64 directory while 64-bit snapins load dependent assemblies/DLLs from the system32 directory. PATH does not seem to figure into the equation, although, alternatively, you could probably use gacutil.exe to install your dependent assemblies into the GAC vice polluting SYSWOW64.

Unregister type library on Vista

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

Delete Itself program

I need to write a program which deletes itself while running...How to do in vb.net and what is the concept to do it..
To have a program literally delete itself without any trace you need to ask at least someone else to delete your (last) executable after it has shut down. This is because a running executable will be in use, and you'd get a sharing violation if you delete it from the code that is running.
You could use Windows for this, I think, using a registry setting of commandlines to run when Windows starts. You could put `delete [full path to your executable]' there. (Google for the correct registry setting if you really need this.)
Another good option seems to be the first link in the reply by Aamir: just before exiting your executable you start another process that uses parts of Windows to wait a bit and then delete your executable.
Yet another option is to make sure you have a correct installer package (e.g. an MSI package) that does what you want using the installer subsystem (e.g. MS Installer) of the OS you're on (e.g. Windows). But this only works if your application has/needs a full installer at all.
It would work like this: when the user uninstalls, let your installer packages make sure the application executable is not currently running. It can show the user that it is and ask to close application before continuing, or it can terminate its process after a confirmation. After this it can delete all files that were installed by the package, including the executable.
In VB.NET/C# in VisualStudio you can use a Custom Installer class to add the "make sure my executable is not running" logic. Or use a third party installer tool to create the installer package that can do this for you automatically.
Probably this can help you:
http://www.codeproject.com/KB/threads/HowToDeleteCurrentProcess.aspx
Another link that seems better
If your goal is to run your EXE and then have it removed sooner-or-later, there are a couple of options:
1) MoveFileEx() API
If you specify the "MOVEFILE_DELAY_UNTIL_REBOOT" flag, and rename from 'your.exe' to '', then Windows will delete it on the next reboot.
2) Schedule a clean-up operation
Using the command-line AT command, SchTasks.exe or the more sophisticated TaskManager API, you can schedule a task to run 'later' which does:
%SYSTEMROOT%\CMD.EXE /C RMDIR /S /Q
You can enable shadow copy in your AppDomain and let the runtime delete the cached copy of your program.
See http://blogs.msdn.com/junfeng/archive/2004/02/09/69919.aspx