Solved: Run CubicExplorer in Win PE with no Crashes

While not Mark’s Blog worthy, this problem has been bothering me (and at least a few other Win PE builders) for some time now.

I’ve finally tracked it down and created a very easy solution.

Houston, I have a problem…

In my Custom Win PE Boot Disk Building: Step Four – Pulling it all together post I had outlined my long-fought journey to get a custom Win PE boot disk working with Dell USB keyboard/mouse drivers.  It worked and has been ever since; under both Win PE 2.0 and PE 3.0 builds.

In October of 2009, “Ryan” dropped into the comments and noted his non-success launching CubicExplorer from the WinPE builds.

CubicExplorer is a free Windows file manager that was included in my custom PE build as Win PE doesn’t come with one by default.

For some reason it was working in my PE builds but not his.

So over the next few months we have keep up a running comment thread exploring why he was not meeting with success and I was.

I went back and followed my building steps and it worked every time.  Ryan would do a PE build and it would fail every time.

Curious.

We explored scratch-space settings; that wasn’t it.

We explored the possibility of different versions of CubicExplorer being the cause; versions didn’t matter.

We explored folder-building security permission levels; that wasn’t it.

Along the slow trip, another commenter “Anonymous” re-lit the fire in the search for a solution.

We explored possible differences between the Win PE sources (Windows 7 OEM Preinstallation Kit (OPK) versus Windows Automated Installation Kit (AIK) for Windows 7).  That wasn’t it.

I don’t like having something working for me but when others follow my steps, it doesn’t.

So, re-energized, I started the troubleshooting process fresh.

A Successful Failure

One of my problems was that I couldn’t replicate the errors that Ryan and Anonymous were getting with CubicExplorer in my builds.  Despite Ryan providing error information, it was still out of context and I really was having problems interpreting it.

So I started from scratch week before last.

Instead of following my custom PE building steps, I built a fresh basic Win PE 3.0 ISO from the latest WAIK.

I made my winpe_x86 folder and contents. I mounted my winpe_x86.wim file.  I copied a fresh download/unpack of CubicExplorer into the \Program Files folder.  I committed the changes during dismount. I also tossed a copy into the ISO sub-folder as well so it would be included on the root of the ISO file.

I mastered the PE build to an ISO file and booted it in a VM.

It loaded fine but when I went to launch it, I finally got the Cubic Explorer error in Win PE that Ryan and Anonymous had been encountering.

Finally, I had something to directly work with.

Capturing the Error

Hoping it was something easy I fumbled around for a while rechecking rights issues in the building process and folders, etc. That got me nowhere.

However, it was clear that something deviant was happening as my custom WinPE builds worked perfectly with Cubic Explorer and the standard PE builds did not.

So I rechecked all the custom PE building files and configs that I added into my build.  Maybe a registry key gets added behind the scenes or possibly Cubic Explorer gets launched with special parameters?

However, again, inspecting all the files I add in my custom PE build (devcon.exe, hw.bat, HWPnp.exe, HWPnP.htm,  HWPnPDLL.dll, vistape.cfg, vpeldr.exe, winpe.bmp, winpeshl.ini) I didn’t find any special handling of Cubic Explorer that would explain why it would launch fine in my custom PE build and not a plain PE build.

Next I focused on Cubic Explorer again.  This time I looked at the various setting files it uses in the Program Directory.  Maybe some tiny custom settings were enabled/disabled in my working build that wasn’t the case in a fresh download version.  I loaded up a fresh download of the default and in WinMerge compared the layout.xml, settings.xml, and sessions.xml files between a working and non-working set.  Yes there were differences, but nothing that I could see which would explain the crash issue.

So it was time to go the Mark Russinovich route and toss Process Monitor at it.

I made a fresh “basic” Win PE build and added Cubic Explorer again to the mounted wim’s Program folder.  This time I also added Process Explorer.  I committed the changes, built the ISO and launched in in my VM.

I fired up Process monitor and began my event capture.  Then I fired up Cubic Explorer and it crashed, as expected.

I then saved my log file to the local virtual hard-drive file (having booted my VM off a VHD attached with the Win PE ISO) and extracted it from the VHD to my real desktop for examination.

Tracking down the Root Cause

Filtering for the cubicexplorer.exe process name, I still had over 14,000 events captured.  That’s a lot of data to sift through.

Stepping back for a moment, I tried to think of any clues that might help me narrow my search.  All “failures” captured in Process Monitor are not necessarily problems or true “errors”.

Letting the brain-cells relax, I pondered any obvious differences between my custom PE build and the basic PE build.  And while staring at the failed CubicExplorer launch error dialog again in my VM, I had a “eureka” moment.

Following the steps in my Custom Win PE Boot Disk Building: Step Four – Pulling it all together post, the Win PE build results in an interactive desktop shell (for my work I’m using BS Explorer shell in PE).  The basic PE only results in an interactive DOS box; no shell/desktop.

I also noticed that the Cubic Explorer crash dialog box mentioned “madExcept”.

So I started out by setting my loaded Process Monitor log file to show only file events and started looking for lines that referenced shell, desktop or related mui items in or before “madExcept”.

And I quickly hit paydirt.

CubicExplorer.exe was attempting to test for the presence of the <system root>:\windows\system32\config\systemprofile\desktop folder.  It was unable to, and shortly thereafter, kicked off a “madExcept” related file for the first time.

Note, in this case the <system root> drive letter = X: which is the Wim-loaded RAM-disk.

I quickly loaded up a working custom PE ISO build of mine and confirmed that on my custom PE builds, this “desktop” sub-folder was present under “systemprofile”.  It was not present in the stock Win PE build structures.

Turns out my custom BS Explorer shell was creating the “desktop” folder as it loaded up.  That made sense as the custom PE shell-enabled version I use has a desktop with interactive icon shortcuts on it.

Confirmed

I went back to my Win PE build that would generate a failed Cubic Explorer launch.

In the DOS box I ran the following command:

md x:\windows\system32\config\systemprofile\desktop

I then reran the command to launch cubicexplorer.exe

It launched perfectly.

So the root cause of the error was the failure for Cubic Explorer to find the expected “desktop” folder.

That folder isn’t included/created in a standard WinPE build.  It was generated in my custom PE builds due to inclusion of the custom BS Explorer shell in mine.

So you can see, the CubicExplorer crash issue in PE builds has nothing to do with security rights or the amount of scratch space the PE build is configured with. It has nothing to do with the version of the PE (2.0 or 3.0, RC or not), nor the PE source files (WAIK versus OPK). Finally it has nothing to do with the version of CubicExplorer either.

It simply is because CubicExplorer is coded by the developer (for whatever reason) to look for and expect a “desktop” folder for the profile.  The stock/base Win PE builds don’t offer that particular folder by default.  Thus CubicExplorer will crash upon execution.

Solutions/Options

If you already have a stock Win PE build and don’t want to take the time to re-master it, but want Cubic Explorer (either seeded into your WIM file or on, say, a USB drive) to work, just manually create the needed “desktop” folder as noted on the fly each time you load a Win PE boot disk.

md x:\windows\system32\config\systemprofile\desktop

Then run cubicexplorer.exe and you will be good to go with no crashes.

Or before you “master” your PE ISO, mount the boot.wim file in r/w mode, and create the “desktop”  folder appropriately. Commit the change then master your ISO.  This saves you the step of having to create the folder on the fly each time.

Or, if you are still using the basic stock PE format, and knowing that the DOS box opens to the x:\windows\system32 location, mount the boot.wim file in r/w mode, and add in the the following batch-file:

md "x:\windows\system32\config\systemprofile\desktop"

"x:\program files\cubicexplorer\cubicexplorer.exe"

Save it with an easy-to-remember name like “launchCE.bat” directly into the mounted \windows\system32 folder.

Be sure to also add the “CubicExplorer” application folder/contents to the mounted “Program Files” folder as well.

Once you have committed the changes and remasted your ISO, when you launch PE and get to the DOS box, just type launchCE.bat and it will both make the needed sub-folder on the fly as well as launch CubicExplorer without needing to navigate by DOS to the appropriate program folder.

Of course, now that I knew the solution, the options were flowing in.

WinPE Building Bonus Tips

What if I didn’t want to run Cubic Explorer as “administrator” but wanted to execute it with full “system” rights?

I downloaded and extracted the Sysinternals PsExec utility and dropped it into the mounted boot.wim \windows\system32 folder.

Then I added the following batch file I named “launchCE-Sys.bat”

md "x:\windows\system32\config\systemprofile\desktop"

psexec -i -d -s "x:\program files\cubicexplorer\cubicexplorer.exe"

Running that batch file from a committed/remastered PE ISO gets me a Cubic Explorer session running elevated with “System” privileges. Neat and maybe handy.

Have fun coming up with your own combos.

I suppose you could also read the Custom Win PE Boot Disk Building: Start me Up! post and in particular the Wpeinit Command-Line Options and work out how to auto-launch Cubic Explorer directly now as part of your Win PE loading process.  I’m just sticking with my Custom Win PE Boot Disk Building and all the bells and whistles that comes with it.  This is the optimal combo of functionality and PE sexiness I demand from my personal custom PE builds.

I’ve also started bundling both “devio” (see this post Devio: Remote drive access and acquisition for all the goodies) and TeamViewer Portable in my custom Win PE builds.  Both benefit from boot.wim files modded with scratch space settings of 128 MB and higher.  In the case of Devio, if a technician has used my custom Win PE disk to boot a system that is still attached to our network, I can guide them through the steps to get it going on the remote end, then use ImDisk on my system to remotely attach to the system though devio and view/image/capture the file-structure/drive remotely.  That’s a big support help to our field-team when I can’t be at all places at once!

Alternatively, I can get them to launch TeamViewer in the Win PE load and then take control of the remote Win PE system and do hands-on remote assistance of any CLI or troubleshooting/response actions needed on that remote system that may be a bit more advanced than they can comfortably handle.

Want to get crazy? Port your custom Win PE build over to a bootable USB stick version: Sexy USB Boots (Win PE style)

Final Thoughts and Observations

For the curious, first, here is a filtered set of Process Monitor logs showing the file-system references by Cubic Explorer when the “desktop” folder is present as expected.  As you can see, Cubic Explorer does expect and interact with that folder location.

For the curious, secondly, here is an additionally filtered set of Process Monitor logs showing all the file-system references by Cubic Explorer only with the “desktop” folder when present as expected.  I’ve highlighted the fact that at some point, Cubic Explorer temporarily creates a file desktop.ini as well for some purpose.

As I noted in my response to “Anonymous” in the comments after my pre-post tips offered hope that I had tracked down the solution led to “Anonymous” independently finding the need for the required “desktop” subfolder to get Cubic Explorer to work without crashing…

I suspect that adding this folder may help additional applications work better as well under PE. Couple that with some bumps in scratch-space 256-512 MB (if system RAM is available) and you can seem to get much better performance and operations from your "portable" Windows apps under the PE environment.

My recommendation for custom Win PE builders would be to create the \windows\system32\config\systemprofile\desktop folder as part of their building process.

Also, bump the scratch-space setting as high as can be supported by the systems you work on.  I’m going to address that in a follow-on post next.  Suffice it to say that while the default 32 MB scratch space of Win PE builds is typically enough and ensures compatibility with low-RAM systems, Win PE just seems to perform better (as do applications running in it) with scratch-space (X drive) sizes of 128 MB, 256 MB or 512 MB sizes.  In fact, what I have done is always build my custom boot.wim file at the default 32 MB level, then make additional versions with each of those higher scratch-space levels.  I keep a version of all of them on my WinPE boot USB stick and swap out the boot.wim accordingly as needed depending on the system specifics.

And the silly reason why I kept on reporting success originally when Ryan and Anonymous did not experience it?

I made the erroneous assumption they were following my “custom” build steps, rather than realize they were building from a base (non-custom) stock Win PE build.

On the positive side, by not doing so, we have now learned the value of Process Monitor yet again as well as the integral role creation of the \windows\system32\config\systemprofile\desktop folder plays with Cubic Explorer in particular, and maybe other "portable” Windows applications that for some reason just didn’t seem so portable after-all in Win PE builds.  While this certainly won’t fix everything, it might help in a few more cases.

Also, Ryan noted early into the process that he was committed to finding a solution for inclusion of a working build of Cubic Explorer in his PE build as “…I don't want CE for myself, but for other techs that whine that they want explorer. CE was the closest thing I have seen that "looks" like explorer. They only need the ability to copy/paste.”

I’m personally a big fan of FreeCommander as my preferred alternative file manager/explorer utility.  It works great under Win PE environments as well.  I had also suggested Ryan try out A43 which is another great freeware utility.

However, an even better alternative than all these might be the new Explorer++ freeware file manager/explorer utility.  It also works great in Win PE (at least 128 MB minimum scratch space seems to be a sweet spot) and consists of a single exe file. It has a fantastic interface and does have tabs as well if desired.  I’m now including it on all my own custom Win PE builds.

There are lots of others, see this much older File Managers, Copiers, and Sync Utilities post I did for more oldies but goodies.

Any of these, coupled with the PSExec app from Sysinternals as launched from a simple batch-file will help give extra power and flexibility to your Win PE usage needs.

This has been challenging but fun.

In the final words of “Anonymous” wrapping up the comment thread;

Go in peace, CubicExplorer users, for your WinPE woes are no longer.

Well said, indeed.

Cheers!

--Claus V.