Solved

trouble installing a Windows\System32 file to Windows\sysWOW64

Posted on 2014-04-13
24
2,595 Views
Last Modified: 2014-04-28
Hi Experts, I guess this is a follow-up to my question from a week or so ago -
"My application's installation does not write files to \Windows\System32".
    In that question, I was having trouble installing files to a Windows 7 64-bit system using my old defunct installation software (www.install-us.de). I was informed about the free NSIS opensource installation software by Joe Winograd, so I've been learning that lately and thought I had created a successful installation script. I used the script here:

http://nsis.sourceforge.net/A_simple_installer_with_start_menu_shortcut_and_uninstaller

... as a template and it seemed to work fine - at least on my other 32-bit Win XP test desktop computer. I don't have a 64-bit machine here to test it on (my 32-bit XP laptop is my development computer), but I had a chance in the last couple of days to sign in to a user's 64-bit machine to test my script out and I ran into an error. Among other things, my app needs to install 3 files in the target user's System32 folder (or sysWOW64 for 64-bit machines):

mfc42.dll
msvcrt.dll
oleaut32.dll

But during installation on the 64-bit system, it generated this error window:

---------------------------
MyApp Setup
---------------------------
Error opening file for writing:

C:\Windows\System32\oleaut32.dll

Click Abort to stop the installation,
Retry to try again, or
Ignore to skip this file.
---------------------------
Abort   Retry   Ignore  
---------------------------


... when I checked his sysWOW64 folder, these files were there, but they may have already been there from before, as apparently they are fairly standard system files. Also, all my app's files were copied to the user's $INSTDIR folder correctly. Anyway, overall the installation failed as my app wouldn't run - I would assume because of this error message in one way or another. Would someone who is good with NSIS be able to help me out? I thought I did pretty much everything right - I have the requisite:

RequestExecutionLevel admin

...command, which allows privileges to Administrator-type systems.

And here's the relevant "install" section of my NSIS script:

section "install"
	# Files for the install directory - to build the installer, these should be in the same directory as the install script (this file)
	setOutPath $INSTDIR
	SetOverwrite on
	# Files added here should be removed by the uninstaller (see section "uninstall")
	file "MyApp.exe"
	file "MyApp.ini"
        file "testdata.txt"
        file "MyApp.ico"


	# Add any other files for the install directory (license files, app data, etc) here

        # Add Windows\System32 files here, these should NOT be removed by the Uninstaller
        SetOutPath "$WINDIR\System32"
        SetOverwrite ifnewer
        File "C:\WINDOWS\system32\mfc42.dll"
        File "C:\WINDOWS\system32\msvcrt.dll"
        File "C:\WINDOWS\system32\oleaut32.dll"
        SetOverwrite on
        File "C:\WINDOWS\system32\sortsol.dll"
        File "C:\WINDOWS\system32\SortSolX.ocx"
        ExecWait 'regsvr32.exe /s "$WINDIR\System32\SortSolX.ocx"'
        File "C:\Code-lock\Code-Lock.ocx"
        ExecWait 'regsvr32.exe /s "$WINDIR\System32\Code-Lock.ocx"'
        File "C:\Code-lock\zlib.dll"

 
	# Uninstaller - See function un.onInit and section "uninstall" for configuration
	writeUninstaller "$INSTDIR\uninstall.exe"
 
	# Start Menu
	createDirectory "$SMPROGRAMS\${APPNAME}"
	createShortCut "$SMPROGRAMS\${APPNAME}\MyApp.lnk" "$INSTDIR\MyApp.exe" "" "$INSTDIR\MyApp.ico"
        createShortCut "$SMPROGRAMS\${APPNAME}\Uninstall.lnk" "$INSTDIR\uninstall.exe"

	# Registry information for add/remove programs
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "DisplayName" "${APPNAME}"
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "UninstallString" "$\"$INSTDIR\uninstall.exe$\""
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "QuietUninstallString" "$\"$INSTDIR\uninstall.exe$\" /S"
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "InstallLocation" "$\"$INSTDIR$\""
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "DisplayIcon" "$\"$INSTDIR\MyApp.ico$\""
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "DisplayVersion" "$\"${PRODUCT_VERSION}$\""
	# There is no option for modifying or repairing the install
	WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "NoModify" 1
	WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "NoRepair" 1
	# Set the INSTALLSIZE constant (!defined at the top of this script) so Add/Remove Programs can accurately report the size
	WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "EstimatedSize" ${INSTALLSIZE}

        MessageBox MB_OK "Click OK to reboot please"
          Reboot
sectionEnd

Open in new window



Thanks!
    Shawn
0
Comment
Question by:shawn857
  • 12
  • 9
  • 3
24 Comments
 
LVL 78

Assisted Solution

by:David Johnson, CD, MVP
David Johnson, CD, MVP earned 250 total points
ID: 39998193
Don't install these files as they are part of the Operating System.

File "C:\WINDOWS\system32\mfc42.dll"
        File "C:\WINDOWS\system32\msvcrt.dll"
        File "C:\WINDOWS\system32\oleaut32.dll"
        SetOverwrite o

Open in new window

n

You should be using %programdata% vice c:\windows\system32 or put your .dll's in to %ProgramFiles(x86)% if you test and it is a 64 bit operating system if a 32 bit O/S then put it in %ProgramFiles%\yourcompanyname\yourappname
0
 

Author Comment

by:shawn857
ID: 39998200
oh okay, so no need to even install those file then eh? They will always be there, on any types of Windows systems, for both 32-bit and 64-bit?

Also, I'm afraid I didn't really follow what you wrote here:

"You should be using %programdata% vice c:\windows\system32 or put your .dll's in to %ProgramFiles(x86)% if you test and it is a 64 bit operating system if a 32 bit O/S then put it in %ProgramFiles%\yourcompanyname\yourappname "


What is "vice"? Is that a reserved word of some type in NSIS script language?

   I don't think I can put my DLL's (code-lock ocx, sortsolx.ocx, sortsol.dll, zlib.dll) into %programfiles% - the makers of these products say they must go in the Windows\System32 folder.

   Also, I'm a total newbie with NSIS - I don't know how to test if the target computer is 32 bit or 64 bit.

Thanks!
    Shawn
0
 
LVL 51

Accepted Solution

by:
Joe Winograd, EE MVE earned 250 total points
ID: 39999683
Hi Shawn,
<mfc42.dll>, <msvcrt.dll>, and <oleaut32.dll> are all part of the Visual C++ redistributables:
http://support.microsoft.com/kb/259403

I believe they'll all be in System32/sysWOW64, but I'm not sure about that. I've never seen them not there, but that's always been on running systems where other software has been installed — I suppose it's possible that they could be missing on a Windows install before any other software has been loaded.

I don't want to speak for David, but I'm guessing that "vice" was supposed to be "vs". I know that "vice" is not an NSIS command — you may find this alphabetical list of NSIS commands helpful:
http://nsis.sourceforge.net/Alphabetic_list_of_NSIS_commands

I believe what he was trying to say is that you shouldn't be writing your files to System32/sysWOW64, but rather to %ProgramData% or %ProgramFiles%. However, when we discussed this same thing in your last question, you said that the manufacturer of your security module (to protect your software from hacking/cracking) explicitly claims that it must be installed to the user's System32 folder (and registered there with regsvr32.exe). I have no clue if that is accurate.

In any case, here's an idea for you, but I've never used this myself. The standard install of NSIS creates an include file called <x64.nsh> with a few macros that are helpful for installs on 64-bit systems. It is located here:

c:\Program Files (x86)\NSIS\Include\x64.nsh

One of the macros is RunningX64, which checks to see if the installer is running on a 64-bit system. Another one is DisableX64FSRedirection, which disables file system redirection, meaning that writes to System32 should actually go to System32 rather than being redirected to sysWOW64 (likewise, there's an EnableX64FSRedirection macro to enable file system redirection).

I've built a lot of installers with NSIS, but I emphasize that I've never tried the above. I offer it up for your testing and evaluation. Btw, I suggest trying to write a funky-named file to System32, something like <aabbyyzz.xml>, to make sure that it doesn't duplicate a file already there and that it is an easy file to check for to see if it was actually written. Regards, Joe
0
 

Author Comment

by:shawn857
ID: 40000110
Hi again Joe, thanks for the reply. OK, so I guess there's no need of trying to install mfc42.dll, msvcrt.dll, and oleaut32.dll.... I'll just take those right out of my script altogether. That should make things a bit simpler. yes, the author of the security module I use does say his OCX should be installed to System32. In previous tests using my old "Install-Us" installer software on the 64-bit machine it got automatically redirected to sysWOW64 and that's fine - it worked from there. So I think I'm okay with letting my OCX files and sortsol.dll file install to sysWOW64. I think my problem now is trying to get NSIS to install correctly using Administrator privileges, as evidenced by the error I got :

Error opening file for writing:

C:\Windows\System32\oleaut32.dll

Click Abort to stop the installation,
Retry to try again, or
Ignore to skip this file.


Thanks for the suggestion for the x64 macro, but I don't think I should be installing my ocx/dll files to the System32 folder on 64-bit machines - I think it's doing the right thing by automatically redirecting them to the sysWOW64 folder... no?

Thanks
    Shawn
0
 
LVL 51

Expert Comment

by:Joe Winograd, EE MVE
ID: 40000137
I think my problem now is trying to get NSIS to install correctly using Administrator privileges, as evidenced by the error I got :

Error opening file for writing:

C:\Windows\System32\oleaut32.dll

Click Abort to stop the installation, Retry to try again, or Ignore to skip this file.
I'm hoping that will go away when you stop trying to write to System32. All of my NSIS installers require admin rights when UAC is turned on, via this statement:

RequestExecutionLevel admin

I've never seen it fail.
I think it's doing the right thing by automatically redirecting them to the sysWOW64 folder
Yes, agreed.
0
 

Author Comment

by:shawn857
ID: 40000192
Yep, I'm using that same statement too:

RequestExecutionLevel admin

Here's hoping getting rid of trying to install those C++ dll's will fix it.

Joe, is there a way to get NSIS to write out a "log" of what it does when it goes through an installation procedure - which files get written, which don't, what happens behind the scenes, etc ?

Also, I noticed on my user's 64-bit Win 7 system that those C++ dll's were present in BOTH his Windows\System32 AND Windows\SysWOW64 folders. Is that okay? Shouldn't they be in only SysWOW64?

Thanks!
   Shawn
0
 
LVL 51

Expert Comment

by:Joe Winograd, EE MVE
ID: 40000371
> write out a "log" of what it does

There's no automatic logging of what it does, but there is a LogText command that your install script may execute:
http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.12

Also, take a look at these macros:
http://nsis.sourceforge.net/Logging:Enable_Logs_Quickly

> C++ dll's were present in BOTH his Windows\System32 AND Windows\SysWOW64 folders. Is that okay?

Yes, it's OK that they're in both. If you take a look at them, you'll see that they are different files. For example, in the W7 Pro 64-bit system that I'm writing this post on, the <mfc42.dll> in System32 is 1,359,872 bytes and dated 3/11/2011, while the <mfc42.dll> in sysWOW64 is 1,137,664 bytes and dated 3/10/2011.

Btw, since you're a software developer, and considering how important the 64-bit environment is these days, I strongly recommend getting an inexpensive W7 or W8 64-bit system on which you can test, perhaps even a refurbished machine to keep costs down (I suspect you can get something in the $200 range). Your 32-bit XP laptop is at the end of the road as a development computer and many of the prospective customers for your software are likely to be on W7 and W8 64-bit systems. Regards, Joe
0
 

Author Comment

by:shawn857
ID: 40000786
OK Joe, tried another test on my user's Win 7 64-bit system.  The good news is that I didn't get that error anymore:

--------------------------
Error opening file for writing:

C:\Windows\System32\oleaut32.dll

Click Abort to stop the installation,
Retry to try again, or
Ignore to skip this file.

.... so *that's* fixed, but the bad news is that it looks like my script didn't register my ocx files. cause my app would not run right when I launched it. I had "ShowInstDetails" set to  "show" in my NSIS script so I could see the installation's progress and it didn't show any error or anything on these lines:

ExecWait 'regsvr32.exe /s "$WINDIR\System32\SortSolX.ocx"'
ExecWait 'regsvr32.exe /s "$WINDIR\System32\Code-Lock.ocx"'

it showed:

Execute: regsvr32.exe /s "\Windows\System32\SortSolX.ocx"'
Execute: regsvr32.exe /s "\Windows\System32\Code-Lock.ocx"'

but it looks like my script is trying to run regsvr32 in Windows\System32, when in fact my OCX files aren't in the System32 folder at all - they're in the SysWOW64 folder. But it didn't show an error that the files weren't found.  Strange...

So I went into DOS mode and went into the SysWOW64 folder and tried manually executing regsvr32 on both ocx files, but for both I got this error message:

[Window Title]
RegSvr32

[Content]
The module "Code-lock.ocx" was loaded but the call to DllRegisterServer failed with error code 0x80004005.

For more information about this problem, search online using the error code as a search term.

[OK]


So it appears my NSIS script is not registering my OCX files correctly - that's the culprit. Any thoughts?

Thanks!
   Shawn
0
 
LVL 51

Expert Comment

by:Joe Winograd, EE MVE
ID: 40000803
> So I went into DOS mode and went into the SysWOW64 folder and tried manually executing regsvr32 on both ocx files, but for both I got this error message

The fact that it failed when you tried to do it manually says that NSIS is not the culprit. When you say, "I went into DOS mode", I'm guessing you mean that you opened a command prompt in W7/64-bit (if that's not what you mean, let me know what you do mean). Instead of a normal command prompt, try doing the regsvr32 commands in an elevated command prompt. There are numerous ways to open an elevated command prompt. One is Start>All Programs>Accessories, then right-click on Command Prompt and select "Run as administrator". Regards, Joe
0
 

Author Comment

by:shawn857
ID: 40010005
OK Joe, I'll try that tomorrow... I've been away for a few days.

Thanks
   Shawn
0
 

Author Comment

by:shawn857
ID: 40010649
OK Joe, I followed your suggestion and the OCX files successfully installed! How can I do this within my NSIS script?

Thanks!
   Shawn
0
 
LVL 78

Expert Comment

by:David Johnson, CD, MVP
ID: 40010667
vice means instead of singular of versus (vs).  As for the software requiring to be in Systrem32 that is an OLD programming practice that is outmoded and against Microsoft best practices.. To keep things organized, place the .OCX into the same folder as the software executable.
0
Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

 

Author Comment

by:shawn857
ID: 40010819
I understand, thanks David. I use a 3rd party anti-cracking module that the author says should be installed to the System32 folder (or syswow64 on Win64, I guess). He doesn't mention if it would be possible to install to the application installation folder - worth a try, it'll either work or it won't.
    I also install a 3rd party sort routine (a DLL file and a OCX file). The author of this says it can be installed to the System32 folder, or any folder in the search path - so I suppose it would be okay to install this to the application folder.

Shawn
0
 
LVL 51

Expert Comment

by:Joe Winograd, EE MVE
ID: 40010822
David,
Thanks for the explanation of "vice". I had never heard it defined as "instead of", but I did find that definition ("in place of", actually) in the dictionary, although it does not say that it is a singular form of "versus", which it defines as "in opposition to". In any case, thanks for adding a new word to my vocabulary!

Shawn,
I'm glad you were able to register the files in an elevated command prompt. As far as doing this in NSIS, I have never run an elevated command prompt in an NSIS installer (I have also never written files to System32 or sysWOW64 in an NSIS installer). I would have thought that running the entire installer with the "RequestExecutionLevel admin" statement would suffice, but if that's not the case, you could try ExecShell (since ExecWait is not working for you):

ExecShell "runas" 'regsvr32.exe /s "$WINDIR\System32\SortSolX.ocx"'
ExecShell "runas" 'regsvr32.exe /s "$WINDIR\System32\Code-Lock.ocx"'

I've never used ExecShell in an NSIS installer and I don't know if the above will do what you want. Some web research indicates that the "runas" action won't work if UAC is turned off. Can't hurt to try it, but I really think you should contact the vendor of your security module to see if those files can be stored in %ProgramFiles% rather than System32/sysWOW64. If you can't contact the vendor or they don't respond, give it a try — see if they'll work when stored in %ProgramFiles%. Regards, Joe
0
 
LVL 78

Expert Comment

by:David Johnson, CD, MVP
ID: 40010826
if the file has setup in the name or is a msi then windows elevates it sometimes silently.  Usually you get the UAC prompt right away.
0
 

Author Comment

by:shawn857
ID: 40011958
David - so if I simply rename my installer file to "MyAppSetup.exe", that might elevate it?

Thanks
   Shawn
0
 
LVL 51

Expert Comment

by:Joe Winograd, EE MVE
ID: 40011984
Hi Shawn,
I realize you addressed that question to David, but I wanted to make it clear that the NSIS statement "RequestExecutionLevel admin" will give you admin rights when UAC is turned on, whether or not "setup" is in the installer file name. Are you not getting the UAC prompt? It should look something like this (if your installer is not code-signed):

UAC unknown publisherThis raises another point. As a software dev, it's a good idea to get a code-signing certificate. You would then put this statement at the end of your NSIS installer:

!finalize 'sign.bat "%1"'

The contents of <sign.bat> depends on whose code-signing cert you buy (mine is Verisign, but there are many others out there). Btw, the <!finalize> statement exists only in NSIS 3 Alpha — it is not in NSIS 2 (current production). With a code-signed installer, the UAC prompt will indicate a verified publisher and your customer will be able to view your certificate:

UAC verified publisherRegards, Joe
0
 

Author Comment

by:shawn857
ID: 40013091
Thanks Joe - yes, the "User Account Control" window prompting the user does indeed appear.

Thanks for the suggestion about Verisign certification, but that's a $500 expense I can't really afford right now... :-(

When I get access to my tester's Win 7 64-bit machine I'll try these further suggestions and get back to you with how I made out!

Cheers
    Shawn
0
 
LVL 51

Expert Comment

by:Joe Winograd, EE MVE
ID: 40013129
Hi Shawn,
I agree that spending $500 on a cert is not the right way to go under your circumstances. You could actually buy a decent W7/64-bit machine for that, which would really be good for your software dev work. In fact, you could probably get something for around $300 so you wouldn't have to slow down your dev by getting access to your tester's W7/64-bit system every time you need to try something. That said, I paid only $99 for a Symantec/Verisign code-signing cert for one year. Regards, Joe
0
 

Author Comment

by:shawn857
ID: 40028008
Hi guys, OK here is my current status with this: When I used my old "Install-Us" installation software, my app mostly installed correctly on 64-bit systems and all it's OCX files were registered properly - only problem was that files written to my app's installation folder didn't have full read/write access. On the other side of the coin when I used NSIS full read/write access was no problem, but my app wouldn't run correctly after installation (I don't think NSIS was registering my OCX files correctly). Anyway, to make a long story short, I reverted back to my old Install-Us installation software and used the "icacls" command within that and it solved my read/write access problems... so now my app installs and runs perfectly. So I guess (for now), I'll be sticking with my old Install-Us installation software instead of using NSIS.

Thanks
   Shawn
0
 
LVL 51

Expert Comment

by:Joe Winograd, EE MVE
ID: 40028044
Shawn,
Thanks for the update — very interesting! It's always helpful to know what works and what doesn't work. Thanks for posting. Regards, Joe
0
 

Author Closing Comment

by:shawn857
ID: 40028147
Thanks guys!

Cheers
   Shawn
0
 
LVL 51

Expert Comment

by:Joe Winograd, EE MVE
ID: 40028261
Pleasure! It was a very interesting thread! Regards, Joe
0
 

Author Comment

by:shawn857
ID: 40028355
Thank you Joe.
0

Featured Post

What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Suggested Solutions

I hope this helps those who have been battling the SanDisk / U3 problem for a while. For anyone that is running Windows 7 64bit and is receiving and searching the internet for the “Windows Error: Windows has allocated a drive letter to the U3 dri…
Today, still in the boom of Apple, PC's and products, nearly 50% of the computer users use Windows as graphical operating systems. If you are among those users who love windows, but are grappling to keep the system's hard drive optimized, then you s…
This Micro Tutorial will teach you how to change your appearance and customize your Windows 7 interface to your unique preference. This will be demonstrated using Windows 7 operating system.
This Micro Tutorial will give you a basic overview of Windows DVD Burner through its features and interface. This will be demonstrated using Windows 7 operating system.

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now