I just got my first 64-bit Windows notebook. Now I'm looking for information when and why to use the 32 or the 64-bit versions of PowerShell or ISE.
My first impression is that I better stay with 32 bit, until I understand things better.
What I miss or didn't find are basic tutorials and practical experiences and links to this questions.
I'am working on a Seven 64Bits and W2K8 R2 for one year now, and, on the command line, I'am always using 64 bits Powershell without any troubles.
For me the problem is not to choose 32 or 64 Bit PowerShell.exe, but to know that the two exists, and that a 32 bits process will use the 32 bits PowerShell. For example if you use PowerShell as post build execution script in Visual Studio 2010, it will use 32 bits PoweShell because Visual Studio 2010 is 32 bits process.
The two versions see two differents places in the registry so you have to Set-ExecutionPolicy for both.
As scripting is concerned I do not use ISE, but PowerGUI script Editor. You can use
[intPtr]::size
in a script to know if you are runing 32 or 64 bits PowerShell.exe.
You would use the 64 bit versions of PowerShell or PowerShell ISE where the problem you are trying to solve is uniquely 64 bit. For example:
You need your PowerShell script to be able to consume more memory than a 32 bit application will allow
You are consuming libraries that are 64 bit only or need to run in a 64 bit environment. For example on Windows 2008R2/IIS7.5 if you are using the Microsoft.Web.Management managed wrapper, if you need to modify administration.config via this library then your application or script needs to run in a 64 bit process.
I typically stick with 64-bit PowerShell unless I have a good reason to not use it. One issue with 32-bit PowerShell is that you may accidentally find yourself in HKLM:\SOFTWARE\Wow6432Node location of the registry instead of where you think you are.
The example I've most-often come across for an explicit need for 32-bit is when using certain COM objects. For example, if you have a 64-bit OS, but 32-bit Office... If you want to instantiate a Word, Excel, or Access object, you're going to need to be in 32-bit PowerShell or else it's going to act as if you don't have Office installed at all.
When running SharePoint 2013, it's important to run the 64-bit versions when attempting to user the Windows.SharePoint.PowerShell snapin. I spent too much time not realizing I had open the 32-bit ISE not being able to load SharePoint Commands.
I think you don't really need to take care about that. As for my 64bit system, there is only a 32bit PowerShell preinstalled (in \system32) and it works without any issues. So just use it ;) And well, besides that, it's most likely the same case as with any other application: if you rely on functions/properties that are only available under 64bit you are better of to use the 64bit version of that application.
Related
If you look at this Youtube video, you can see that WinDbg is automatically executed when the process dies.
I've followed the tutorial and tried to do the same on my system. I first ran windbg -I, and then changed the HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Auto registry key to 0. Is there any other step that I'm missing?
Running the 64-bit version of WinDbg with -I command line option creates both 64 bit and 32 bit AeDebug entries. This can easily be proven with Process Monitor:
The 32-bit version of WinDbg creates 32 bit entries only. So, if you ran the 32 bit version, 64 bit programs are not handled. That's what I expect has happened. Another option would be that you ran it without administrative privileges and didn't read the failure message carefully.
In case you want both 32-bit and 64-bit crashes to be handled by WinDbg, run WinDbg -I for both versions. You'll find that WinDbg is smart enough to handle any order:
WinDbg32 will overwrite an existing entry created by WinDbg64 before
WinDbg64 will not overwrite an existing entry created by WinDbg32 before
Although WinDbg64 can debug 32 bit applications, it cannot load 32 bit extension DLLs, therefore you typically want both debuggers registered, not only the 64 bit version.
I'm trying to learn the basics of dll injection, so I created a really simple hello-world type DLL and an injector based off of code I found online. I wasn't able to find anything that works out of the box, so I had to make a few adjustments.
Injection Code, DLL Code
I'm running these on 64-bit windows. I'm compiling with Visual Studio 2010. The injector is a win32 console app, and the dll is win32 as well. I'm trying to inject my code into an existing notepad process (also 32-bit). All of this is running on Windows 7 x64.
When I run the injector, it fails every time at CreateRemoteThread, with GetLastError returning 5 (i.e. ERROR_ACCESS_DENIED). I've confirmed that the dll path is correct (although changing it to a bogus path gives the same behavior), and I've confirmed that the path is getting written to notepad's memory at the correct address using Cheat Engine. I'm having a difficult time with this because I'm not sure how to debug the problem further.
What could be causing CreateRemoteThread to fail?
The problem is that notepad.exe is a 64-bit process in 64-bit windows, and I was trying to inject with a 32-bit process.
I also come up with the same problem. My situation is this:
My system is 64-bit and the notepad is also 64-bit.
But the injector is the 32-bit process.
My solution is to replace the 64-bit notepad with the 32-bit notepad in the system directory.
This isn't my area of expertise so I'm asking hopefully the right question.
We have a server that is lease rolling. The old server is a 32-bit windows server and the new server is 64-bit windows 2008 R2 SP1.
One of the web applications uses Perl to run some scripts.
We can run the same 32bit version on the new 64-bit machine? (e.g. if there is a same version but one is 32-bit and one is 64-bit, are they essentially the same?)
If a script is working on a 32-bit version, should it still work under the 64-bit version of Perl?
If the questions need clarifying, please let me know and I'll see about asking the appropriate person on our team.
I think the answers to both your questions are yes. The 32-bit applications should run fine on your 64-bit Windows, but will not be able to utilize any of the 64-bit features (where a larger usable address space may very well be the most important if you ever want to parse big XML using XML::Twig ;-).
The script running under 32-bit perl will work on a 64-bit perl, provided you get all the modules for the 64-bit perl in order, since they typically run from different directories. Also, be aware that for 64-bit perl on Windows you probably need Strawberry perl, ActiveState perl or similar. Cygwin is only 32-bit as far as I know.
Yes, you can, as long as you redeploy properly, including the build steps for dependencies. Just copying files over will only work if the whole application stack is pure-Perl, which is not likely. — Yes, they are essentially the same, but binary incompatible.
Likely yes. Problems can arise with the dependencies, however the number of modules that fail due to 32-bit/64-bit differences are miniscule.
If you're concerned about compatibility, you should be able to run the 32-bit version of perl on the 64-bit machine (assuming both are x86). But the 64-bit version should work more or less the same as the 32-bit one, with a couple of exceptions that should not affect scripts. (They have to do with C/XS code in modules, mostly. Binary-compatibility stuff. Meaning modules will have to be built for 64-bit. Fortunately, any Perl interpreter that doesn't suck will do the build stuff for you in the case of *nix, or provide a package manager that has pre-built modules like ActiveState does.)
I am trying to use a 32 bit wix installer to install to the powershell directory c:\windows\????\windowspowershell\v1.0
i have hard coded the 32bit directory
and i am trying to read the registry to return the 64 bit location.
all works fine on a 32bit machine, the registry gets read with the correct value and the file is installed to the correct place.
however when running on a 64bit machine (server 2008 R2) the registry picks up the correct 64 bit location but my hard coded 32 bit location is overwritten with the 64 bit registry value.
what is going on?
is there a better way of doing this?
what i have is a single ps1 script that needs to be installed to the powershell directory, if there is a 64 bit and 32 bit directory the same file should be copied to both locations
thanks
James
Windows Installer was designed to be platform specific. X86 packages can only write to X86 locations and X64 packages can only write to X64 locations. There are some hacks that allow you to get around this but they aren't supported. The official Microsoft solution is to create multiple MSI's and use a bootstrapper to chain them together ( ugly ) but you can also use a custom action to copy the file to the secondary location.
Sorry, no good solutions on this one IMO.
I want to run some system commands (to fix things) before running an executable. I have a reasonably locked down (work) Windows XP system and so can't change what a shortcut points to. For my users' convenience, I must keep the same shortcut. However, I am able to swap out the .exe (renaming) and potentially replace it with another .exe (of the same name) which runs my system commands and then runs the original .exe.
What would be the easiest and quickest language/compiler to do this in? Previously, I've done this sort of thing in C (and tried it today in Python using py2exe without much success). Preferably free solutions.
Visual C# 2008 Express Edition is
free
comes with a compiler
outputs exes
C# is a good choice if you have C
experience
.net currently is the "canonical"
Windows platform