MustangPE plugin is now available for TI 2016

Awesome.  Thank you!

Mustang wrote:

I've added a plugin for TI 2016 to my website. It will work with all builds of TI 2016. It can be used to build 32 and 64 bit versions of MustangPE.

It reports as virus by many anti-virus programs. Please notify those companies that it is a false positive. I know that it is often happens to AutoIt scripts but still it is good if it will not be removed by installed anti-virus programs, including Windows Defender. Many of the anti-virus companies are fixing the progrem within a month after getting report of false positive.

Here is a link to results of scanning https://www.virustotal.com/en/file/88f18be6a63a4f30902c96c3b4c8cc16519a…

Hallo And Do

See Post #93:

https://forum.acronis.com/de/node/71918?page=1#comment-264323

Thanks but I know that! I am also often sending suspicious files to the Avira and here is a report I got from them:

Dear Sir or Madam,

Thank you for your email to Avira's virus lab.
Tracking number: INC........
 

We received the following archive files:

A listing of files contained inside archives alongside their results can be found below:

http://forum.acronis.com/forum/71918#comment-231092

Mustang wrote:

As I mentioned in reply #26, anti virus companies have a problem with programs written in the AutoIt 3 language. There is a high level of encryption when the programs are compiled. They can not be decompiled, even by me. Earlier versions of AutoIt 3 used to compile using a password and could be decompiled using that password. That feature has been removed. Because the anti virus companies can't see inside the files, they report them as potential virus. This results in all the companies reporting a different virus signature.

I went through dealing with an anti virus company with the 64 bit version of the TI 2014 MustangPE plugins. See reply #31 in this thread https://forum.acronis.com/forum/54130 . It was a lengthy process that I am not willing to repeat. MustangPE is something I now do for free to help the community. I could just stop offering MustangPE to solve the problem. Let's hear from some users. If the consensus is the false positives age too scary, I'll withdraw MustangPE.

As I told before I know about that "problem" already But it is good to Be in a White List than in a Black List to avoid unnecessary problems.

Paul:

Thank you for your continuing support of MustangPE. This latest version is turning out to be the best one yet.

I'm currently working the bugs out of a 64-bit build based on WinPE 10. It is being built in a 32-bit Win7 VM. I am getting an error message; see the attached figure for the exact wording. Four of these errors appear in rapid succession early in the build process before adding plugins. See the attached figure. But if you click "OK" to dismiss the error each of the 4 times that it appears, the build proceeds to completion. It works, other than two small issues.

TI 2016 works
DD 12 works
Opera browser works
PENetCfg works
A43 file manager works

I'm building using version 3.3.8.1 of MustangPE Builder ADK, downloaded on June 29 from your web site. The version of WindowsKits being used is 10, downloaded from Microsoft on the same day, build 10586 of WinPE 10.

Have you seen this error message? I'm wondering if it has anything to do with the small issues in the build.

The small issues are:

1. Network name resolution doesn't work with this build. To map a network drive (in either A43 or PENetCfg) you have to use the IP address instead of \\server\share. Name resolution works fine on my last build of MustangPE 2015 based on WinPE 8.1 but not on this one based on WinPE 10.

2. Very minor - the icon for TI 2016 on the LaunchBar in the /Programs/Acronis folder is replaced by a generic icon instead of the one for TI. See the desktop picture. DD12's icon is fine as are all of the others in the build.

On the bright side, WinPE 10 has all of the network drivers for all of the machines in the house, so there was no need to add drivers to the build like there was with WinPE 8.1. They "just work". I hope you'll pardon the desktop wallpaper substitution - we have different "Mustangs" here of the non-automotive kind.

Here is something else that I discovered that you may want to point out. If you UEFI boot on a machine with Secure Boot enabled, the PENetCfg application will not run. The error message is "Unable to start the TCP/IP Registry Compatibility service. This service is required by PENetCfg to work properly under the Windows PE 2.0 environment". In the build, I did enable test signing in the BCD per your instructions in the ReadMe.txt file that is located in the PENetCfg plugin folder. However, when secure boot is enabled the BCD in the EFI system partition on the machine being booted is used instead of the modified BCD on the flash drive. If you list the BCD contents post-boot you can see that testsigning is not enabled, thus PeNetCfg will not start. If you try to enable testsigning by using bcdedit you get an error message that says that Secure Boot is blocking changes to the BCD.

To work around this and have PENetCfg working you either need to turn off Secure Boot before booting MustangPE or else boot the flash drive in Legacy (BIOS) boot mode. All of the other applications in MustangPE work fine with Secure Boot enabled.

Any comments on the error messages during the build process?

Hi Mark,

I have it all working with a UEFI boot with Secure Boot enabled. One thing I can tell you for sure is that test signing doesn't work with Secure Boot Enabled. The way I am getting around the problem is that TI 2016 has a problem with the digital signature of the fltsrv driver. This is causing a BSOD on boot. I get the boot to continue by hitting the F8 key to bring up a menu and selecting F7 to override digital signature driver enforcment. Then the boot completes. This makes PENetCfg work even though test signing has not been enabled.

The only thing I am doing different than you is I am using an earlier version (10240) of the ADK. I don't get any error messages during tha build. The icon for TI 2016 build 6571 is correct. I am able to map a network drive using PENetCfg with the computer name\share name format. The only thing I do is make sure the WORKGROUP designation is set to match the network before mapping a drive letter.

Paul:

I've not been able to figure this out. The WORKGROUP designation is correct. Still, PENetCfg refuses to do name recognition no matter what I try, although it's perfectly happy with IP addresses when connecting to shares. It must have something to do with the build number of WinPE.

I do not get a BSOD on boot from TI's fltsrv driver like you do, even though the version of TI2016 is the same as yours (build 6571).

There's supposed to be a new build of Windows 10 released on August 2, so maybe I'll try again if Microsoft updates WinPE at the same time. Otherwise, I'll just keep using my earlier build of MustangPE based on WinPE 8.1 which doesn't have this issue.

I definitely think the BSOD is because I'm using the 10240 ADK. I think the issue is solved with the 10586 ADK. I stay with the 10240 ADK because I worked out adding support for runnibg 32 bit apps in the 64 bit WinPE. This was way too much work to do over again with the 10586 ADK. I'll be sticking with 10240 for quite some time. 

I found the problem with name recognition on the network. It turned out that my router's DHCP server has a setting to append a domain name to the networking settings when it hands out leases. I had used my last name as the network's domain name. I don't know why I did that. Dumb.

This version of WinPE didn't like having domain names, or I didn't know how to deal with them when entering network names. After removing the domain name from the DHCP server in the router I am now able to use the \\server\share method to access network resources.

So I like this build with Windows 10 ADK 10586. The boot.wim file is smaller than the one from Windows 8.1 ADK; 325 KB vs. 479 KB. Both builds have the same applications installed. Maybe someday someone will figure out how to get PENetCfg x64 to work with secure boot enabled.

Glad to hear you got it working.

You should be able to get PENetCfg to work with Secure Boot enabled by installing a dummy service that has a sys file without a proper digital signature. That will cause the BSOD and allow you to hit the F8 key to bring up a menu and then hit the F7 key to override driver signature enforcement. I haven't been able to figure out how to make WinPE enable overriding driver signature enforcement automatically. Maybe there is a registry entry to accomplish this, but I haven't been able to find it.

One thing that still troubles me about this build is that the boot.wim file for the Windows 10 ADK 10586 is significantly smaller than one I did last year with the Windows 8.1 ADK 9600. That just doesn't seem right, so I wondered what else might be missing. I found something that was. The "Properties" choice in the context menus that you see in A43 file manager when right-clicking on a file, folder, or disk drive are not working. In last year's build they worked, even displaying a graphic for a disk drive's properties. A43 is the same version in both builds. So something isn't right or I've done something wrong. As a result, I don't trust this build as much as I trust last year's build of MustangPE 2015 which I've used for imaging, recovery, disk partitioning, BCD editing, and general repairs without issue. I'll give this another try the next time that Microsoft updates the Windows 10 ADK.

I was, however, successful in integrating MustangPE into the graphical Recovery screens on Windows 10 so that it is always available without needing to boot from a flash drive or CD. That worked out very well. The method is posted in the TrueImage 2015 forum: https://forum.acronis.com/forum/123055 and should work for any WinPE-based build.

There seems to be good news and bad news every time Microsoft introduces a new version of WinPE. The good news is better driver support. The bad news is that more and more things are left out. The Properties contect menu item in A43 is not working with ADK 10240 either. Also drag and drop file copy is no longer working in A43.

Mustang,

Could you create an add-on for the portable version of explorer++ or just add the folder into the image and leave a shortuct on the desktop to launch and use from the desktop?  Not as nice as complete integration into the PE environment, but might function a little better.  I know that WinPESE doesn't comply with WinPE ilcensing (or some third party software), but it's just so darn handy, I can't convince myself to revert back to other versions of WinPE anymore. MustangPE is the next best thing for sure though. 

Thanks for the suggestion about using explorer++. I gave it a try. The program runs in WinPE, but there is nothing displayed in the left hand pane.  

Ah, there's a fix for that and I just tested it out.  Seems to be fully functional now.

https://explorerplusplus.com/forum/viewtopic.php?t=1232

On your WinPE disk, create a Desktop folder for the user profile being used. For example, on my WinPE, the value for %USERPROFILE% is 'X:\Windows\System32\config\systemprofile'. Just create folder 'X:\Windows\System32\config\systemprofile\Desktop' before launching Explorer++. This will fix both the Folder View problem and the copy-paste issue.

If you want to avoid creating this folder each time you boot, you will have to mount the boot.wim file and add the folder there.

The fix helped. The Folder view was fixed. Copy and paste worked from the icons in the toolbar. Copy and paste didn't work from the right click context menus. Drag and drop file copy didn't work with either the right or left mouse buttons.

When I get some time, I"ll write you a plugin for Explorer++ and post a download link here. If you can find fixes for the above mentioned problems, I"ll include the plugin in MustangPE.

Thanks, I'll do some more testing and see what I can find. Doesn't look like development has happend for a few years though, but it's the best alternative to A43 I've come across natively (so far). 

You can download the MustangPE plugin for explorer++ here : http://www.mechrest.com/plugins/MustangPEBuilder/Downloads/Files/Explorer++.zip . It can be used with both the 32 bit and 64 bit versions of MustangPE.

I tried Explorer++ in a build based on ADK 10586. At this point I think it's a toss-up between A43 and Explorer++.

• Explorer++ has more features and looks a lot like the File Explorer in Windows 10, but it doesn't have a convenient method for mapping network shares - after you enter the net use syntax in a command prompt, network shares can be accessed through the GUI.
• A43 has a menu for mapping shares where you don't need to resort to a command prompt or remember the net use command's syntax.

Both have the same problems with some items on the right-click context menus and drag and drop not working. I think it's a toss-up.

Both Explorer++ and A43 have problems in WinPE. I have been using Total Commander to move files around in WinPE. The drag and drop feature is working. There is a MustangPE plugin for Total Commander on my website.

In WinPe built with the latest Win10 ADK, Explorer++ copy/paste, left hand menu contenxt for copy/paste and icons for copy/paste are all working for me.  Drag and drop is non-functional, but right click copy/paste for WinPE use seems useful enough.  Total commander isn't bad either.  I basically keep all of these in my portable apps distro and use whichever does the trick for what I need it to, but usually use explorer++.  I've also added a small .bat script to map a network share on my default user profile so that it just prompts for username and password and that makes mapping a network drive pretty simple.  If you want, you could have this run automatically as part of the startnet.cmd file or as a logon task.  

The login script is a reasonable compromise. I added the line net use z: \\server\share /user:username * to the AutoRun.cmd file and now when MustangPE starts, it prompts me to enter the server's login password and the share is mapped at startup.

I still see the same issues with context menus using the latest ADK based on Windows 10, version 1607. But for now I will live with the inconveniences.

For those of you who have tablet PCs without keyboards, there is a way to build MustangPE with pen and touch support. I had just upgraded my Microsoft Surface 3 tablet to Windows 10 version 1607 yesterday and I noticed that the Winre.wim file that was upgraded on the tablet was 306 MB, whereas the winpe.wim file in ADK 1607 is 212 MB. On the tablet, touch is enabled in the recovery environment so the larger file size makes sense.

To enable pen and touch support in MustangPE, build with the file Winre.wim from the tablet's recovery folder instead of building with the file winpe.wim that comes with the ADK. Rename the file winpe.wim in the ADK to winpe.old and then go to your tablet's Recovery folder and copy the file Winre.wim to your ADK build environment, renaming it winpe.wim. Then run MustangPE builder. I did this for a 64-bit build and then used the technique described in the link in reply #13 to add MustangPE to the graphical recovery screens in Windows 10.

On my Surface tablet this worked out extremely well. It was so much easier to use touch to move or resize windows, select menu choices, etc. rather than using a keyboard and touchpad. Even the bluetooth pen worked, amazingly. Using the new command prompt editing features that simplify selecting, copying, and pasting was much easier by touch or pen instead of typing cryptic GUIDs out on a keyboard. This is a joy when editing the BCD.

The only anomaly that I noticed in this build was that the desktop wallpaper was replaced by a black background, which is the way it looks when starting the normal recovery environment on the tablet.

Mark,

Here is a plugin for adding a menu item to activate the Windows Recovery Environment from within MustangPE when you are using winre.wim for the build. It is only for the 64 bit version of MustangPE. It has the added bonus of fixing the wallpaper issue. You only need to replace winpe.jpg in the Files folder of the plugin with your own jpg. http://www.mechrest.com/plugins/MustangPEBuilder/Downloads/Files/WinRecEnv.zip .

Thanks to both Mark and Mustang - very cool.  

Do we know if the winRE.wim is system specific (as the ADK is generic)? If there is touch support in the WinRE and no downside to using it on other types of hardware, I would probably build WinPE using the WinRE in the future to have that  extra usability.

Bobbo:

Nice to make your acquaintance! I can't answer your question definitively, but here is an answer based on a sample of two. I upgraded both my desktop and a Surface tablet to the Anniversary edition of Windows 10 v1607 in the last couple of days. The Winre.wim file on the desktop is 330,680,600 bytes (315 MB) while the one on the Surface tablet is 320,916,776 bytes (306 MB). ?? I would have expected the one on the tablet to be larger because it contains pen and touch components and an on-screen keyboard. So that's a surprise.

Paul:

Thank you very much for supplying the extra plugin. It's interesting in this regard. WinRE on the Surface tablet can be operated entirely in slate mode without a keyboard or mouse. The command window pops up an on-screen keyboard that you can touch-type on so that a keyboard isn't needed. When I build MustangPE based on this .wim file, touch and pen support are working on all apps, including the command prompt window. But the on-screen keyboard is missing.

After installing your plugin, I can start WinRE from the MustangPE desktop. After following the menus to a command prompt, the window opens on the MustangPE desktop and it does have the on-screen keyboard (OSK). But the OSK only works in this one command prompt window. You can get clever and open Notepad from the command prompt and use the OSK to enter text into Notepad, and it does copy/paste from there to other applications in the MustangPE desktop, as long as there is a menu item for Paste. So you cannot, for example, open TrueImage to do a backup entirely from a slate tablet. The TI app will eventually want text entries and you can't paste text into TI without having a keyboard to do Ctrl-V. So it's a partial solution for owners of slate tablets. Admittedly, I'm still experimenting with it so I may yet discover a way to make do without a keyboard.

Interestingly, if you open A43 after opening the WinRE command prompt, clicking on the Terminal Window icon in A43 will start a new command prompt window WITH the OSK.

And you have to be careful not to close the first WinRE command prompt window because it will drop you back into the recovery menu structure and the only ways out lead to a reboot of the machine.

Again, thanks for your effort with this, I really appreciate it.

Mark,

I agree that if you use WinRE the only way out is to reboot. I like it in MustangPE because I can use it on a dead machine without needing to have a Windows installation DVD handy.

Rob,

If your Windows installation was from a Windows installation DVD, winre.wim should not be machine specific. As Mark has seen, if you upgrade a Windows installation, Microsoft may supply a machine specific winre.wim or add necessary drivers for your machine. I don't know how they handle this.

Winre.wim can be pulled from a Windows installation DVD. You need to get the install.wim file from the DVD and mount it with dism.exe. If it doesn't mount, it means it is in esd format. In that case you need to get a program to convert it to wim format. I use WimReducerESWimConverter. Winre.wim can be found in the mounted image. I don't remember that exact loction off the top of my head.

Thanks, 7zip can snag it out on it's own without having to mount - I use this as a cheat to pull files from .wim files all the time and turns out it can navigate .esd files too - pretty cool.  For reference, the winRE file is located at:

Win10_1607_x64.iso\sources\install.esd\1\Windows\System32\Recovery\winre.wim\

The one I created with the media creation tool for Win10_1607 on a Win10 Pro x64 desktkop is only 293Mb - perhaps it already pulls the drivers from the machine during the creation process - not really sure.  Glad to have learned something new :) 

Rob,

Thanks for the tip on 7zip. I'll give it a try.

Rob,

I gave it a try and it didn't work. Then I updated 7zip to build 16.02 and it worked like a charm. Thanks again for the great tip.

Paul:

I'm curious about your comment in reply #28 that you like having Windows Recovery Environment in MustangPE becuase you "can use it on a dead machine without needing to have a Windows installation DVD handy". What tools are in Winre.wim that aren't already present in a build of MustangPE?

I'm thinking of the startup repair option.

2016 Plugins,

Morning, first a big thanks for all the time effort & help you provide to our members.  I hope you'll spare a few minutes to reply to a question or 2...Within our extended family we have 7 ATI2016 licensed products.  I want to prepare for each person/PC a 2016ATI WinPe (using your plugins) hopefully both as a DVD and USB.

To my question, our PCs include Win7 (both x86& x64) as well as Win 10 (also both x86 & x64).  I'm trying to see if I can avoid have to prepare these (7 DVDs and7 USBs) on eacg PC...some of which are spread around the country. 

1.  Am I able to prepare these (4 variants {w7 & w1, in both x86 & x64) WinPEs with your plug in in my one, say on the same PC, using a single ADK (w7/w8.1/w10 (which version ADKs).  Or perhaps at least reduce the number of preparation-cycles? 

2. If you see this as possible, and to provide the best results, which (1) or two "mother Preparation Pcs usings which ADKs) would you choose? So, I hope you understand what I'm trying to accomplish & can provide a some insite as (in my book) the expert.

My only recent expereince was preparing a 2015 WinPE USB (this one not using your plugins) for which I used ADK 8.1, which seemed to add native USB3 for Win 7 systems..at least to the extend the USB3 chipset was native to ADK8.1 Prepped on a W7-x86 pcs, it "seems fine:

Looking forward to your wisdom!

Bob

You will only need to prepare 2 variants (one for 32 bit systems and one for 64 bit sytems). You can prepare both on a Windows 10 64 bit system.  You will need to download and install both the 32 and 64 bit versions of MustangPE. You can use either the Windows 8.1 or Windows 10 ADK. You will be able to create both an ISO file for DVD and a USB drive.

The same TI 2016 MustangPE plugin works in both the 32 bit and 64 bit versions of MustangPE. Follow the instructions in the ReadMe.txt file to get the TI 2016 files to add to the plugins.

Boot the 32 bit version of MustangPE on 32 bit systems. Boot the 64 bit version of MustangPE on 64 bit systems. When you boot MustangPE you need to choose the boot option that matches your system. Boot in Legacy mode for 32 bit systems and 64 bit systems that are set up on MBR disks. Boot in UEFI mode for 64 bit systems that are set up on GPT disks.  You don't need to disable Secure Boot on UEFI/GPT systems.

....You ARE THE MAN.  Thx, with your knowledge of this area (PE etc) I know you know you stuff  One last point, you recommend preparing (as you noted) on the W10 64 bit system, uisng either the  8.1 OR Win 10 ADk.  As I've had good luck in the past with the 8.1 ADK my thoughts would be to use that...as I know there are at least 2 variants of the W10 ADK....and what actually works with "what" seems sketchy frm other posts  I've read.

sounds correct?

Have a great weekend

Bob

Dear Acronis MVP Volunteer;

Am using TI 2016 Build NBR 6571.  My PC is Windows 10 Version 1607 that was updated from V.1511 on 2016/08/11. My internal HDD has two partitions.

One is C and another one is F.  Complete backup is made on the external HDD.  After Win 10 updated, the backup data on the external HDD is indicated as follws;

  AUG12_full_b1_s1_v1.tib

    > C:

    >NTFS(1-3)

    >F:

My question is what NTFS(1-3) does mean.  Before Win 10 update to V.1607, NTFS(1-3)  was not appeared.

Please kindly make advice to me.

Best Regards,

Yoshi

栄住 中町 wrote:

Dear Acronis MVP Volunteer;

Am using TI 2016 Build NBR 6571.  My PC is Windows 10 Version 1607 that was updated from V.1511 on 2016/08/11. My internal HDD has two partitions.

One is C and another one is F.  Complete backup is made on the external HDD.  After Win 10 updated, the backup data on the external HDD is indicated as follws;

  AUG12_full_b1_s1_v1.tib

    > C:

    >NTFS(1-3)

    >F:

My question is what NTFS(1-3) does mean.  Before Win 10 update to V.1607, NTFS(1-3)  was not appeared.

Please kindly make advice to me.

Best Regards,

Yoshi

It is most likely an additional 450 MB Recovery partition created by Microsoft during the upgrade to build 1607.

I just built a 32bit MustangPE2 WinPe using the Windows 10 Anniversary Update ADK and the TI 2016 plugin. Everything worked as expected except for Penetcfg. As soon as I launched Penetcfg it triggered a BSOD:

System Thread Exception Not Handled

Failed: Netio.sys

Any thoughts on the cause of the problem?

You did better than I did with that ADK. I built a 32 bit MustangPE on a 64 bit Windows 10 Anniversary system (build 1607) using the 1607 ADK and the resulting MustangPE was not bootable. I don't know why. It will be a long time before I can find time to work on the problem.

As of now, I can't offer any help with the PENetCfg problem.

Thanks Mustang. I had searched on PeNetCfg and didn't find any issues with it. I will rebuld with a different ADK and see what happens.

I rebuilt with ADK for release 10240, the orginal and PenetCfg did not give a BSOD.

Dear Mustang;

Thks for your comment. My PC is also 32bit Windows. The build number of TI 2016 is 6571.  Process time to make the backup and to make that for the recovery is the same as before Windows update to V.1607.

I can not undestand the definition of terminology as following;

1: What ADK stands for ?

2:MustangPE, what stands for ? and what function is ?

3: Mustang Plugin, what function is ?

Please kindly advice.

Thks & Rgds,

Yoshi

I did some more testing with the 1607 ADK. This time I built a 64 bit MustangPE. I was able to boot the resulting build. However, I was not able to get PENetCfg to run. I changed the start value of the tpcipreg service to 0 to make the service start during boot. This had the desired effect of causing a BSOD due to tcpipreg.sys not having a certified digital signature. I should have been able to hit the F8 key followed by the F7 key to disable driver signature enforcement. This procedure works with previous ADK's. It doesn't work with the 1607 ADK. I was not able to continue with the boot.

I am giving up on using the 1607 ADK! 

Mustang, I'm quite happy with the most recent build I did using the 10240 ADK. I appreciate all of your efforts over the years.

Paul:

I don't know whether you would consider a different PE Network Manager. I am using this one: https://sourceforge.net/projects/penetwork/ in a couple of recent WinBuilder projects. It's a 64-bit app and runs perfectly in a WinPE built using ADK 1607 that EFI boots with Secure Boot enabled.

Mark:

I gave it a try in the 64 bit version of MustangPE. Running PENetwork.exe gave the following error message:

An error occured while starting the "TCP/IP Registry Compatibility" service (2)!

Did you use this in Win10SE?

Paul:

Yes, Win10PE SE.

I understand the WinBuilder build process is different from MustangPE since WinBuilder uses the Windows installer ISO as a source while MustangPE uses the ADK ISO. There must be some components missing from the ADK that are necessary for starting the TCP/IP Registry Compatibility service. Too bad; the PENetwork project has some really nice features.

The reason it works in Win10PE SE is because they figured out how to disable driver signature enforcement. The are starting the tcpipreg service with a driver that does not even have a digital signature. I haven't been able to figure out how to do that.

Once again, thx for all you do...refering to the above answer you kindly provided, pardon my ignorance in this matter.  I fo fully understsnd that you specified thst i should prepare both an x86 and x64 sets then use them on systems that are x86 or x64 as appropriate.

This leaves one final, but important question, when preparing these two variants, do they need to be created on pcs belonging to the x86 and x64 variants.  Put another way, can i prepare, for example, x64 and separate x86 versions on the same pc, just selecting the appropriate options.  Or must i CREATE ( versus later boot on...) the x64 version on an x64 pc and CREATE the x32 on an x32 pc?

i hope u understand my wuestion.

thx sgain

bob