How To Use .NET and PowerShell in Windows PE

Something that has been a source of frustration to many IT staff is the lack of support for .NET and PowerShell within Windows PE. Although there are many good reasons why this is not included – memory usage/size of boot images being among the reasons…it is still an unfortunate thing being limited to Win32 .EXEs, VBScript, or AutoIT. Unfortunate because with Microsoft’s promotion of C# .NET and PowerShell for so long, many of us have grown to love the power and simplicity of these frameworks/scripting languages. Having to write utilities for PE in Win32 C++ or VBScript is a serious pain. Every time I have to go back to VBScript/HTAs I cringe, and as much as I love C++ after being pampered so long in .NET there is some frustration whenever I have to use it. So I wanted to come up with a workaround solution until someday we may get proper support.

My first approach was just to try and copy the .NET framework files into my PE image, with a few reg keys. However this method did not succeed. So I needed to find a way to understand what exactly got installed as part of .NET and PowerShell. To assist with this process I decided to use ThinApp. ThinApp is an Application Virtualization solution from VMWare that allows packaging an application and all relevant frameworks into a portable executable file. The latest version of VMWare Workstation includes a personal use only license. Problem with ThinApp that it is typically licensed per machine, and although if you have appropriate licensing ThinApp’ing .NET + PowerShell is in my opinion the best way to go with WinPE. In any case by creating a ThinApp package of .NET + PowerShell we can get in a really simple format the information we need to make the framework run in PE.

As .NET 3.5 + PowerShell is part of Windows 7, and even removing the feature seemed to leave much of it behind, it was not going to be a suitable OS to do a capture. So to start I went back to my arch nemesis Windows XP. The process was basically this:

1)      VMWare’s Workstation automated install on a Windows XP SP3 retail CD.

2)      Installed ThinApp into the VM

3)      Launched ThinApp Setup Capture

4)      Performed a “Prescan” of the System

5)      Installed .NET 2.0 SP1 (NetFx20SP1_x86.exe)

6)      Installed PowerShell 2.0 (WindowsXP-KB968930-x86-ENG.exe)

7)      In ThinApp Setup Capture performed a Postscan and Build. I now have an output folder with all the reg keys + all the files that have changed since the prescan phase. In addition I have a “bin” folder which contains the portable .EXEs that I can take & run anywhere ThinApp is licensed

The reg keys are exported in a format like this:

So using this information I have built a batch file to collect all the required .NET registry keys and files. Probably there are many more reg keys then really required, I can’t be bothered to go and eliminate unnecessary ones. If you have any suggestion let me know.

Running this batch file in Windows 7 will result in a file collection about 740 MB in size.  On a clean Windows XP SP3 with .NET 2.0 SP1 + PowerShell 2.0 it will be about 200 MB in size. Both the XP and Windows 7 version will run in Windows PE 3.0 fine. (I haven’t tested earlier versions of PE)

The batch file below can be downloaded here:

Running this batchfile on a machine with .NET and PowerShell installed will generate a folder “Installer” in the directory the batch file is stored. Beneath that two directories will be created Files and Reg.

To install .NET in PE this is what you must do

1)      Copy entire contents of Installer\Files folder into root of your BOOT.WIM (X:\)

2)      Open the NET_FRAMEWORK.reg file in Installer\REG folder using a text editor and search replace C: to X:

3)      Import NET_FRAMEWORK.reg after WinPE has booted. (Some reg keys here may cause a BSOD if you import it into your WinPE hives directly.)

Note: I’ve only tested this on x86 WinPE, may need some modification to work on x64 WinPE. Some potential issues to keep in mind for WinPE x64:

  • .NET on x64 system typicall includes a 64-bit + 32-bit Framework (i.e. 64 bit in C:\Windows\Microsoft.NET\Framework64 and C:\Winodws\Microsoft.NET\Framework for 32-bit. If you only want 64-bit remote the Framework folder, and ensure relevant registry keys are all pointing to C:\Windows\Microsoft.NET\Framework64. Your .NET apps should be complied to either Any or x64
  • .NET executables can be compiled to force using 32-bit Framework, for these to work you need to include the 32-bit subsystem in x64 WinPE + 32-bit .NET Framework (there is no supported way to do this, but if you want to know how to do it let me know)

About chentiangemalc

specializes in end-user computing technologies. disclaimer 1) use at your own risk. test any solution in your environment. if you do not understand the impact/consequences of what you're doing please stop, and ask advice from somebody who does. 2) views are my own at the time of posting and do not necessarily represent my current view or the view of my employer and family members/relatives. 3) over the years Microsoft/Citrix/VMWare have given me a few free shirts, pens, paper notebooks/etc. despite these gifts i will try to remain unbiased.
This entry was posted in .NET, Batch Files, PowerShell, Windows PE and tagged . Bookmark the permalink.

16 Responses to How To Use .NET and PowerShell in Windows PE

  1. Neil says:

    Thanks for the wonderful instructions. I have followed them but how do i get powershell to run? When I change directories to the \v1.0 directory and type powershell.exe nothing happens. I have imported the reg file correctly with the c:\ changed to x:\

    • What OS version did you capture the files from & what OS architecture? (i.e. if you run SET PROCESSOR_ARCHITECTURE from command line what is the result – both in your client OS and WinPE)

      1) You should use 32-bit host OS to capture files for 32-bit WinPE -> or if you are using 64-bit host and 32-bit WinPE you must capture files from the \SysWow64 and \Framework64 folders instead)
      2) i’ve only test capture from 32-bit host OS to 32-bit WinPE
      3) If it’s failing to launch you need to determine if file/reg keys are missing. To do this you need to use ProcMon in your PE session ( and look for items where result is NAME NOT FOUND.

  2. Aaron says:

    I am running into the same issue. Procmon shows 45 items with NAME NOT FOUND. Looks like I have some research to do. :)

  3. Gutharius says:

    1) Copy entire contents of Installer\Files folder into root of your BOOT.WIM (X:\)

    Do we replace any existing files or no?

  4. Jake says:

    I’d like help getting syswow64 to run in x64 WinPE. I’ve tried, but so far all I get are side-by-side errors when I try to run a 32bit notepad :-(.

    BTW – great tutorial. Thanks!

  5. I always seem to get “mscorwks.dll could not be loaded” errors. I must be doing something fundamentally wrong here. I might just start looking and the Windows 8 ADK, which seems to include a WINPE installation with .NET framework plugin capability.

    • yeah I’d used Windows 8 ADK now. I don’t know why it didn’t work for many people; this process works for me. Maybe I do something extra without even noticing it…in any case it all can be diagnosed with ProcMon running in PE. But ADK now supports .NET 4.0 (you won’t be able to use .NET 2.0/3.5 apps tho)

  6. Daniel says:

    The downloadlink for the batch file is down :(
    Is a reupp possible? I really need this.

  7. Tom says:

    Fantastic guide! Is a re-up possible for the batch file?

  8. michu says:

    can you reupload the it will be really great :)

  9. Rick says:

    It would nice if the file could be made avaiable. I’d like to try it with WinPE 3.1 just to see if I can get Powershell to work.


  10. neces says:

    some Pentium 4 processors can not boot WinPE 4. Therefore WinPE 3.1 is a must.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s