Table of Contents
- Frequently Asked Questions
- General
- Can I use Winbuilder to build PhoenixPE?
- Is PhoenixPE a clone/fork of Win10PE_SE/Win10XPE/etc.?
- Building PhoenixPE seems complicated. Why shouldn't I just use a pre-built ISO like Bob.Omb / Hiren's / Gandalf's / MediCat / Sergei / etc.?
- Why don't you just use PortableApps.com for App Scripts?
- Can you include XYZ application in PhoneixPE?
- Do I need internet access in order to build PhoenixPE?
- What if I have slow internet or poor reliability?
- There is a new version of program xyz.exe available. Can I update the script myself?
- What is Run from RAM and when should I use it?
- Win11 Support
- Common Issues
Frequently Asked Questions
Table of Contents
General
- Can I use Winbuilder to build PhoenixPE?
- Is PhoenixPE a clone/fork of Win10PE_SE/Win10XPE/etc.?
- Building PhoenixPE seems complicated. Why shouldn't I just use a pre-built ISO like Hiren's/Gandolf's/Medicat/Sergei/etc?
- Why don't you just use PortableApps.com for App Scripts?
- Can you include XYZ application in PhoneixPE?
- Do I need internet access in order to build PhoenixPE?
- What if I have slow internet or poor reliability?
- There is a new version of program xyz.exe available. Can I update the script myself?
- What is Run from RAM and when should I use it?
Win11 Support
Common Issues
- Bluescreen/Issues testing with VMWare/VirtualBox
- My Anti-Virus software says PhoenixPE contains a virus
- SetACL - Error: Could not grant full permission...
- Rufus "Revoked UEFI bootloader detected" Warning
General
Can I use Winbuilder to build PhoenixPE?
No. Winbuilder is no longer developed an contains numerous bugs, some of which are critical. Winbuilder bugs aside PhoenixPE also makes use of PEBakery exclusive features and additional commands that are not present in Winbuilder.
Is PhoenixPE a clone/fork of Win10PE_SE/Win10XPE/etc.?
No. It's an alternative. The projects have completely separate origins.
PhoenixPE development started in 2014 as a Winbuilder project and was originally envisioned as a replacement for the Win10PE_SE project, which had become bloated and hard to maintain. In 2016 PhoenixPE was re-written from the ground up using the new open-source PEBakery engine, providing me with the opportunity and challenge of coding a project from scratch without Winbuilder bug workarounds, hacks, and bloat built up over a decade of Vista/7/8/8.1/10 WinPE evolution. The development of PhoenixPE also assisted greatly in the testing, documentation, and development of the PEBakery engine.
Win10XPE was released as a Winbuilder project several years later in March of 2018, shortly after Misty released ChrisPE as a PEBakery proof-of-concept project. ChrisPE was named as both a play on PEBakery (crispy...PEBakery...get it? ha. ha.) and as a tribute to longtime developer ChrisR after he announced his retirement from maintaining the Win10PE_SE project.
Both produce a similar WinPE environment based on decades of community members working together. We aren't in competition.
Win10XPE does great at providing a simple, pre-packaged experience, however at it's core the code-base is cumbersome and inconsistent and in an effort to provide a simple user experience it loses the flexibility and ease of customization advanced users crave.
PhoenixPE on the other hand targets users and developers looking for more control over how and what goes into their PE. PhoenixPE's modular architecture and robust API combined with the stability and speed of the PEBakery engine make it simple for users of all skill levels to build, flexible enough for the most advanced users to modify/tweak, and easy for developers to maintain.
TL;DR: No. It's an alternative. The developers of both projects are part of a vibrate community that works together and shares their knowledge and experience. Use the one that best meets your needs. You can't go wrong.
Building PhoenixPE seems complicated. Why shouldn't I just use a pre-built ISO like Bob.Omb / Hiren's / Gandalf's / MediCat / Sergei / etc.?
Almost all popular pre-made ISOs are based on either Win10PE_SE, Win10XPE, or PhoenixPE. Unfortunately, many of them show their thanks by removing references to the original projects and authors while taking full credit themselves. They include a handful of outdated portable-apps, apply some visual tweaks, add pretty graphics, slap their name on the ISO, and throw it up on a fancy website. Some even bundle Warez, which puts you at legal risk, or hide freely available software behind paywalls. To make matters worse, the software included is almost always outdated — leaving you exposed to known security vulnerabilities and at the mercy of whenever the distributor last felt like putting out an update. And since you have no visibility into exactly what's baked into that ISO, you're simply trusting a stranger on the internet to provide you with a tool that will be run with full system access. In the end, you're just using someone else's custom build, stuck with their choice of apps, their customizations, their update schedule, and their definition of "safe".
There can be nothing wrong with using a pre-made ISO if you just need a quick fix, you trust the distributor, and and are happy with whatever they have decided to include. But if you want to cut the bloat, add your own apps, apply your own customizations, include commercial software with your own license keys, keep everything up to date and secure, and have it all in your native language — building it yourself is the only way to go. You need to put in a little work to reap the rewards, but it's absolutely worth the effort.
Why don't you just use PortableApps.com for App Scripts?
There are a few issues to be taken into account with with pre-packaged applications like those provided by PortableApps.com, SFX Constructor, etc.
-
Using a pre-packaged portable app introduces another 3rd party relationship. Once the original author releases a new version of the software, somebody (usually a volunteer) has to notice and create a new portable app package. This can introduce delays in the update process as PhoenixPE has no control over when or if the package maintainer updates the portable app for the new version. It also leaves us vulnerable to the package maintainer's opinion/idea of what configuration the portable app package includes and what features are available.
-
Disk Space. In some cases the application files are compressed into a self extracting installer (SFX), then extracted to a temp directory at runtime. This can pose some challenges in a WinPE environment because temporary directories are located either in the file system overlay (FBWF/WinPE Cache), or in a RAM Drive. Both typically have very limited space available. FBWF/WinPE Cache is typically 1GB or less and needs to be available to the operating system for it's activities and temp files, and RAM Drives are likewise only configured to use a fraction (10% or so) of the available RAM. Depending on the extracted size of the portable app package and the number of portable app packages a user runs in a given session, this can exhaust temp disk space rather quickly. There are to many trade offs to consider. Make the RAM drive too large and if the user doesn't have enough RAM the drive creation either fails, or it succeeds and there is not enough RAM left for the OS or other applications. Make the RAM drive too small and space is exhausted after only a couple of apps are launched. Either scenario is unacceptable to the end user, who most likely does not understand they need to anticipate and calculate extracted size, physical RAM available on every computer they plan to boot, frequency of use, and the number and disk space requirements of other apps/temp space/etc. in the first place, and can't be relied upon to configure the environment correctly at build time.
-
Customization. Portable apps may not be designed to be pre-configured, and even if they are the process is not any easier then making the needed registry/config modifications at build time. By extracting the original setup file ourselves we can allow the user to configure some application settings via the script interface, such as language, layout, preferences, etc. We can also register and make use of shell extensions, menu integrations, file handlers, services, drivers, etc. that are typically disabled and/or removed altogether in a portable app package, as they just don't make sense in that context.
Can you include XYZ application in PhoneixPE?
Unfortunately it's impossible for us to include every conceivable application in PhoenixPE and everyone has a different idea of what is important or what fits their personal tastes.
PhoenixPE carefully selects applications we include in the main distribution, taking into account among other criteria: popularity, license, ease of integration, ease of maintenance, and perceived usefulness to the community at large.
The great news is, that with PEBakery's user friendly and flexible scripting language and PhoenixPE's robust API, it's relatively easy to make your own scripts and include your favorite applications. Be sure to check out the PEBakery Documentation and the PhoenixPE API.
If you get stuck give a shout out in the forums, there is a good chance that somebody has made a script for a similar application or will be able to answer your questions.
Do I need internet access in order to build PhoenixPE?
Yes and No. In order to comply with Microsoft's software license/distribution requirements PhoenixPE needs to download some tools from the Windows Automated Deployment Kit (WAIK) the first time it is run. Depending on the scripts you select, setup files, language definitions, signatures, etc. for the applications may also need to be downloaded from the author's website, CDN, or an authorized mirror. Once downloaded, the tools and application setup files are cached and will not be downloaded again unless you manually clear the cache, nuke the project, or elect to always download the latest version of a particular program.
TL;DR: Once the initial build is complete and the cache is populated you no longer need internet access for subsequent builds.
What if I have slow internet or poor reliability?
In addition to saving bandwidth, PhoenixPE's cache system was built with situations like this in mind.
On each app script that requires files to be downloaded from the internet you will find a download button on the top right.
You can use this button to pre-download setup files for any scripts you wish to use. Programs will be cached in PhoenixPE\Workbench\PhoenixPE\Programs and used in subsequent builds. Programs downloaded during build time will also be cached in the same location and used in subsequent builds.
Since PEBakery and PhoenixPE are fully portable, it is also possible to place the PhoenixPE install directory on a USB drive or portable hard drive, plug in at someplace with a faster/more reliable internet connection and launch PEBakery to pre-download the apps you need.
As a last resort, you can also download an application's installer manually and place it in the correct cache folder. Be advised that you must know exactly which path and file name that the script will be looking for, so this option is best left for expert users who fully understand how each script operates.
There is a new version of program xyz.exe available. Can I update the script myself?
Sure. Most scripts can be easily updated if you know the program's version number and the download links have not changed.
Updating is usually as simple as opening the script in Notepad++ or your favorite code editor and modifying the ProgramVersion variable under the [Variables] section.
[Variables]
%ProgramFolder%="Notepad++"
%ProgramExe%="notepad++.exe"
%ShellExtDll%="NppShell_06.dll"
%ProgramVersion%=8.6.8
%DownloadURLx86%=https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v%ProgramVersion%/npp.%ProgramVersion%.portable.7z
%DownloadURLx64%=https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v%ProgramVersion%/npp.%ProgramVersion%.portable.x64.7z
Keep in mind that depending on the software, the process may be different, and/or other script modifications may also need to be made. If in doubt ask for help in the forums.
You can also check the master branch on github to see if the script has already been updated but has not yet been published in a release package. Scripts in the master branch are considered stable and ready for general use.
What is Run from RAM and when should I use it?
Many scripts you encounter when configuring and building PhoenixPE will have a '''Run from RAM''' checkbox on the script interface. Enabling the option changes where the program will be installed in PhoenixPE.
If you select Run from RAM the program will be installed in X:\Program Files. (Packed in boot.wim)
If you do not select Run from RAM the program will be installed in Y:\Programs. (Accessible on the CD/DVD/USB boot media)
In order to maximize the available resources you should avoid Run from RAM unless one of the following conditions are met:
- You are booting from the network (PXE). Run from Ram is required in this instance and you should use the Run all programs from RAM option in the Source Config script.
- If the program needs run from a writable directory because it writes log files or config files to its own directory and you are intending to run from read-only media such as CD/DVD. In this case Run from RAM provides a writable environment.
- If the program has drivers, services, or shell extensions installed (these will stop working if the boot media is removed or unmounted).
- You intend to boot from writeable media such as a USB flash drive and want any logs/files created by the program to be discarded on shutdown so the program always starts from a default state.
Reasons not to use Run from RAM:
- You need access to the program files when you are not booted into PhoenixPE. For example you want to be able to run them from the boot media or update the program files or antivirus definitions without rebuilding PhoenixPE.
- Large (> 100 MB) program files? Including these in RAM reduces the amount of system RAM available to PhoneixPE. This can cause memory exhaustion on systems with inadequate resources.
- You are using writable media such as a USB flash drive and want any logs/files/config created by the program to persist on each boot.
Win11 Support
Building from a Win11 source with explorer shell causes blackscreen on boot.
Due to changes to Explorer.exe with Win11 to support the redesigned start menu and taskbar, the Win11 explorer.exe desktop crashes in WinPE. This is due to the new taskbar using WinRT API's that are not supported in WinPE. Make sure you are using a Windows version that is tested and supported by the project.
Common Issues
Bluescreen/Issues testing with VMWare/VirtualBox
It's important to remember when testing with VMWare/VirtualBox you need to take into account the memory and CPU requirements of the PE you will be testing. WinPE is RAM intensive. Remember that just because you configure a VM with 2 CPU's and 4GB RAM, it doesn't mean that it's available to the VM. These resources are shared with the host, and must be free in order to be used by the VM. Errors such as a bluescreen "System Thread Exception Not Found", or hang on PreShell Configuration are almost always caused by incorrect virtualization settings, too little RAM, or not enough CPU resources. Try increasing the resources and/or closing CPU/RAM intensive applications (Web Browsers, games, video streaming, etc.) on the host. Ramdisk size and the size of your boot.wim file all need to be taken into account when determining memory requirements.
My Anti-Virus software says PhoenixPE contains a virus
Please refer to Anti-Virus False Positives.
SetACL - Error: Could not grant full permission...
Users may encounter the following error message:
[Success] [M] ShellExecute - [Standard Output] Retrieving the remote path for mapped drive L<\PE\Workbench\PhoenixPE\Target> failed with: Cette demande n’est pas prise en charge. (ShellExecute,Hide,%Tools%\%HostArch%\SetAcl.exe," -ot #$qfile#$q -on #$q#1#$q -actn ace -actn setprot -op #$qdacl:p_nc#$q -ace #$qn:S-1-1-0;p:full;s:y#$q")
[Success] [M] ShellExecute - [Standard Error] ERROR while processing command line: object (name, type): C:\PE\Workbench\PhoenixPE\Target could not be set! (ShellExecute,Hide,%Tools%\%HostArch%\SetAcl.exe," -ot #$qfile#$q -on #$q#1#$q -actn ace -actn setprot -op #$qdacl:p_nc#$q -ace #$qn:S-1-1-0;p:full;s:y#$q")
[Success] [M] If - [3] is bigger than [0] (If,Not,%ExitCode%,Equal,0,Halt,"Error: Could not grant full permission on#$x#$x#1#$x#$xThe command returned: [%ExitCode%].")
[Warning] [M] Halt - Error: Could not grant full permission on [C:\PE\Workbench\PhoenixPE\Target]. The command returned: [3]. (If,Not,%ExitCode%,Equal,0,Halt,"Error: Could not grant full permission on#$x#$x#1#$x#$xThe command returned: [%ExitCode%].") (Line 1727)
This issue appears to be isolated to users with a host operating system running Win10 LTSC 2021. Starting the WebClient service on the host computer resolves the issue.
Rufus "Revoked UEFI bootloader detected" Warning
In newer versions of Rufus (4.6 and later), you may encounter the following message:
Revoked UEFI bootloader detected
Rufus detected that the ISO you have selected contains a UEFI bootloader that has been revoked and that will produce a “Security Violation” screen, when Secure Boot is enabled on a fully up to date UEFI system.
– If you obtained this ISO image from a non reputable source, you should consider the possibility that it might contain UEFI malware and avoid booting from it.
– If you obtained it from a trusted source, you should try to locate a more up to date version, that will not produce this warning.
The message is not an error, but a warning from Rufus that pretty much all Microsoft Windows UEFI bootloaders prior to May 2023 are subject to the Black Lotus Secure Boot vulnerability and, as result, are in the process of being revoked by Microsoft.
Since Microsoft is not rebuilding the old ISO's with new boot-loaders this is expected behavior, and basically, your stuck with seeing the warning in Rufus as long as you use an older ISO with the vulnerable bootloader.
You may choose to ignore the message or update to more recent ISO to keep Rufus from displaying the warning.