FAQ
Frequently Asked Questions
No. Winbuilder is no longer developed an contains numerous bugs that have not been fixed, 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.
No. PhoenixPE development started around 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 for use with the 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. It also assisted greatly in the testing, documentation, and development of the PEBakery engine.
Win10XPE was released several years later, in March of 2018.
It's an alternative. Both produce a very similar environment based on decades of community members working together. We aren't in competition.
In my option the 2 projects have different goals. Win10XPE states that "it's main objective is to be simple, user-friendly and to be as fast as possible". This caters well to user that just want to press a button and get a working PE without much fuss. Win10XPE does great at providing a simple, pre-packaged experience, however it's core codebase 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 basic/advanced users as well as developers looking for more control over how and what goes into their PE. It strives to be simple for both users to build, and for developers to contribute/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.
There are a few issues to be taken into account with with pre-packaged applications like those provided by PortableApps.com, SFX Constructor, etc.
1. Using a pre-packaged portable app introduces another 3rd party relationship. Once the original author releases a new version of the software, somebody 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 maintainers opinion/idea of what a portable app package includes and what features are available.
2. 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.
3. 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.
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 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.
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. Win11 10.0.22000.0 and prior versions allow you to work around this issue by using explorer.exe from a Win10 source or HostOS. Due to Microsoft's EULA we cannot distribute explorer.exe with PhoenixPE, however the Explorer shell script will allow you to provide explorer.exe from either your Win10 Host or another source.
Update: As of Win11 22H2 (10.0.22621.382) the explorer.exe shipped with the ISO no longer causes a blackscreen.
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.
Please refer to Anti-Virus False Positives.