Why does Test-Path -Path $folder -PathType Container return true, but folder does not exist?
The Path is:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\MyCompany\Modules
Same code in ISE x86 and ISE, but different results
The answer is here
Excerpt:
The 'System32' folder is for 64-bit files and the 'SysWOW64' folder is for 32-bit files
This can be somewhat confusing, but the System32 folder is intended
for 64-bit files and the SysWOW64 folder is intended for 32-bit files.
This may seem a bit illogical if you look at the folder names, but
there is an explanation to this. It has to do with compatibility. Many
developers have hard coded the path to the system folder in their
applications source code. They have included "System32" in the folder
path. And to preserve compatibility, if the application is converted
to 64-bit code, the 64-bit system folder is still named System32.
But what about 32-bit applications that have the system path hard
coded and is running in a 64-bit Windows? How can they find the new
SysWOW64 folder without changes in the program code, you might think.
The answer is that the emulator redirects calls to System32 folder to
the SysWOW64 folder transparently so even if the folder is hard coded
to the System32 folder (like C:\Windows\System32), the emulator will
make sure that the SysWOW64 folder is used instead. So same source
code, that contains a path with the System32 folder included, can be
compiled to both 32-bit and 64-bit program code without any changes.
So remember: • the SysWOW64 folder is intended for 32-bit files only
• the System32 folder is intended for 64-bit files only It is very
important that a binary file compiled to a specific bitness (32 or 64)
is installed to the correct system folder. Otherwise the program that
needs the file will not be able to load the file and will probably not
work as expected.
That's why ISE x86 output is in SysWow64 folder and the call to:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\MyCompany\Modules
is redirected to the SysWow64 folder.
The ISE console is running as x64 and therefore will look in System 32 and will not find this folder, but the folder was created in ISE x86 console, which saves the folder under SysWOW64.
Related
I've just installed SQL Developer 4.1.1 64-bit on a Windows Vista machine, in directory c:\sqldeveloper.
My Java installation is in c:\program files\java and I have two sub- directories:
c:\program files\java\jdk1.8.0_31
c:\program files\java\jdk1.8.0_25
I have modified the jdf.conf and sqldeveloper.conf files in the
c/sqldeveloper/sqldeveloper/bin directory. jdf.conf was empty and I added the following line:
SetJavaHome
c:\program files\java\jdk1.8.0_31
sqldeveloper.conf:
#SetJavaHome ../../jdk <===== This is what is was
SetJavaHome c:/program files/java/jdk1.8.0_31 <======= I changed it to this
I even moved the missing file "msvcr100.dll" it was asking for to the c:/sqldeveloper/sqldeveloper/bin directory.
I got the following error messages:
This application has failed to start because msvcr100.dll was not found.
Re-installing this application may fix this problem
Unable to launch the java virtual machine located at path
c:\sqldeveloper\jdk\jre\bin\server\jvm.dll
The file msvcr100.dll is in the Java directory c:/program files/java/jdk1.8.0_31/bin.
The file jvm.dll is in the Java directory
c:/program files/java/jdk1.8.0_31/bin/jre/bin/server.
I modified product.conf:
#SetJavaHome /path/jdk <===== This is what it was
SetJavaHome C:/Program Files/Java/jdk1.8.0_31 <====== This is what I changed it to
I have a copy of msvcr100.dll in sqldeveloper/sqldeveloper/bin folder and in the c:/program files/java/jdk1.8.0_31/bin folder.
To run SQL Developer I click on sqldeveloper.exe in the c:/sqldeveloper/sqldeveloper/bin directory.
Is I am running it on the correct way?
I ran in to the same problem myself, trying to run SQL Developer 4.1.1 64-bit with JDK on a Windows Server 2008. I've installed SQL Developer many times over the years from 1.x to 4.1.1 and never encountered this until now.
I solved it by copying the MSVCR100.dll file from sqldeveloper\jdk\jre\bin to the sqldeveloper\sqldeveloper\bin folder.
Update 3/18/2017:
In downloading the latest version from Oracle's website, I found this in the installation notes which confirms and explains the issue:
Note: the Windows EXE requires a MSVCR100.dll to run. Most computers will already have this file and in the Windows PATH. However, if the first copy of the file found by the EXE is a 32-bit copy of the DLL, then SQL Developer will fail to start. You can fix this by copying a 64-bit version of the DLL into the BIN directory or updating your OS PATH such that a 64 bit copy of the DLL is found first.
Only create the directory /sqldeveloper/jdk/bin and copy The file msvcr100.dll is in the directory.
Then /bin don't exist is in the /sqldeveloper/jdk
I have faced this similar issue on my local system.
I have solved this issue by copying bin directory from insatallation_directory/jdk/jre to insatallation_directory/jdk/
You need to copy the msvcr100.dll file from sqldeveloper/jdk/jre/bin/msvcr100.dll to sqldeveloper/sqldeveloper/bin/. Then just open SQL Developer again.
You only need to create the directory \bin in sqldeveloper \sqldeveloper\jdk\bin and copy the msvcr100.dll file in this new directory.
Got the same issue with newest versions.
Interestingly enough, msvcr100.dll is present in JRE 1.8.0_251, but not in JRE included in JDK 1.8.0_261.
Even though I run SQL Developer with included JDK, it tried to use my installed JRE 1.8.0_261.
Resolution was simply to copy missing msvcr100.dll from any other place (like jre1.8.0_251\bin or maybe even Windows/System32) to the JRE used by SQL Developer. In my case to jdk1.8.0_261\jre\bin.
I calculated MD5 and SHA256 hash values of notepad.exe and mspaint.exe through online hash generators md5FileCalculator Onlinemd5.
What i noticed is that if i calculate when both exe's are present in their actual postion in system32 the value coming is different than when placed somewhere out of system32 folder.
What is the reason behind that ? Which is the correct hash value ?
I am using Software Restriction policy to block the applications, I created a hash rule for notepad.exe(present in SYSTE32 folder) file and blocked it. When I check the hash value in registry it is different from the hash value of notepad.exe (from SYSTEM32 folder) calculated through other methods like online md5 calculators or through Windows API. But when I copy the notepad.exe file into some other folder say on desktop and calculate the hash value, it is coming same as it is in registry for which I created the rule.So the correct value is I think the one which I get when file is out of system32 folder. But I am not getting why it is happening ? Does it have something to do with permissions ?
It's because of 32-bit applications running on 64-bit Windows, and how Windows handles the System32 folder for those programs.
This was also driving me nuts for a while because I couldn't for the life of me figure out why certain files in System32 (namely .dlls and .exes) were returning different hashes depending on what I checked them with.
Using HxD and Firefox to upload a file to check its hash, I got different results compared to using QTTabBar's hash checker, which runs inside explorer.exe.
But if I copied one of these files to another location, I would then get identical results across all programs.
Meanwhile, HxD showed different file lengths for the copied file vs the one in System32, and while both showed similar byte distribution, there were also significant differences.
But then I thought to try the same thing on another folder, and finally cracked it, with a little help from Wikipedia:
The operating system uses the %SystemRoot%\System32 directory for its
64-bit library and executable files. This is done for backward
compatibility reasons, as many legacy applications are hardcoded to
use that path. When executing 32-bit applications, WoW64 transparently
redirects 32-bit DLLs to %SystemRoot%\SysWOW64, which contains 32-bit
libraries and executables.
32-bit applications are generally not aware
that they are running on a 64-bit operating system. 32-bit
applications can access %SystemRoot%\System32 through the pseudo
directory %SystemRoot%\Sysnative.
Because HxD and Firefox (and most other browsers) are all 32-bit applications, when you load a file into them, Windows is actually transparently redirecting them to the file of the same name in the SysWOW64 folder (presumably if you ran a 64-bit browser, you would not encounter this problem).
Similarly, when you copy a file out of System32 to another location, explorer.exe, being a 64-bit process, copies the original System32 file, and not the (confusingly named) SysWOW64 equivalent.
So as the wiki states, if you enter %SystemRoot%\Sysnative
into the path of the open file dialogue in your 32-bit application, it should load the file from the real System32 folder, and give you the correct result.
And if you check the files in the SysWOW64 directory, all files should return the same respective hashes regardless of what you open them with.
Further reading:
SysWOW64
Sysnative
Are you sure you're checking the exact same file yet on diferent paths? I think you're checking two diferent notepad.exe. Check the size of the file... it must be exacly the same on bytes.
I've just checked my notepad.exe on two distinct paths C:\Windows\System32 and C:\Windows and they are diferent.
This is with respect to this question which I had asked earlier - Powershell: Installing Modules on Target System
What is the default module load path ?
Now after so many days, it has started giving this error (from my C# code)
Cannot find path 'C:\Users\angshuman\Documents\WindowsPowerShell\Modules\MyPSModules\MyPsModules.psd1' because it does not exist.
All the while it was nicely loading from the SysWow64 folder path
Why it is suddenly searching in user folder rather than Windows folder?
I am executing the same code via C# on a Windows 7 64-bit OS
_ps = PowerShell.Create();
_ps.AddScript("Import-Module MyPSModules -PassThru");
Collection<PSObject> psObjects = _ps.Invoke();
And if you want to have them to have a better readability you can use this:
$env:PSModulePath.split(';')
$env:psmodulePath is the automatic variable which holds the path used to discover modules. If it's not set, PowerShell looks in c:\windows\system32\WindowsPowerShell\v1.0\modules and MyDocuments\WindowsPowerShell\modules.
So it should by default always be looking in both places.
I haven't done much 32-on-64 coding, but I could see it using SysWow64 (instead of System32) if you were running a 32-bit app on a 64-bit OS.
When I do this -
PS C:\> $env:psmodulePath.split(";")
I get two folders - i.e. User Module Folder and System Module Folder.
User Module Folder
C:\Users\winUser1\Documents\WindowsPowerShell\Modules
System Module Folder
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
Now, when I am copying my psm1 files under system module folder, and trying to do import-module from ISE x86, the scripts are not getting loaded, but vice-versa is true - i.e. working from user module folder.
But, in a production environment, I want any user to be able to execute the scripts. Any idea how to achieve the same ?
NOTE: I am using Windows 2008 R2 and Windows 7 - All 64-Bit Versions, but scripts should run as 32-bit version
Try to copy them under the SysWOW64 folder. The SysWOW64 folder contains the 32-bit system files and the System32 contains the 64-bit system files
C:\windows\SysWOW64\WindowsPowerShell\v1.0\Modules
I am exploring a Citrix environment and noted that there is are two System32 folders one in the usual location and another under a Citrix folder. What is the difference. When is one used and when is the other used. If I have application specific dll's that I normally put in the System32 folder, should they be in the Citrix\System32 folder instead?
Thank you,
Elliott
Do not put anything in System32 folders! Neither in the regular Windows ones (32 bit and 64 bit), nor in the Citrix one. Use your application's installation directory.
The Citrix\System32 folder is used by Citrix only. Don't mess with it.