Jump to content











Photo

Windows 8.1 (UEFI Boot) Issues


  • Please log in to reply
248 replies to this topic

#1 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 24 June 2014 - 01:48 PM

I have a very harrowing issue that I haven't been able to resolve for literally months...

 

I first noticed the problem when I was trying to implement VHD boot. The boot menu took very long to appear (instead of a few seconds, a few minutes); and after selecting a VHD boot entry, the computer would appear to freeze for about 20 minutes to 30 minutes, before all of a sudden completing the VHD boot successfully.

 

My hardware is a Surface Pro 2. This runs with Windows 8.1 and UEFI boot only.

 

I am currently running experiments with WIMBoot, and again running into many strange issues. Sometimes the boot spinner keeps spinning indefinitely. At other times, there are different kinds of blue screen errors occurring. Things that are simple and should work appear to grind to a halt on this system, and apparently with no explanation as to their cause.

 

For instance, the same VHD boot that stalls the Surface Pro 2 boot menu for a few minutes, and the actual boot for half an hour; works flawlessly on a VMware Windows 8.1 instance (admittedly, that instance is BIOS based, and not UEFI - I have not yet had a chance to experiment with UEFI on VMware).

 

I also got a new Surface Pro 2 when my main one appeared to fail sometime ago. When I tried the same VHD boot process on this new Surface Pro 2, it too worked flawlessly - no delays at any stage. Unfortunately, something must be wrong with the disk imaging software that I use; because after cloning my main OS to the new Surface Pro 2 setup, the same problems started manifesting there as well.

 

I have used both Paragon Hard Disk Manager and Macrium Reflect. Even though I did a full backup of my Surface Pro 2 using Macrium Reflect before even having booted it once with its pre-installed OS; restoring this does not reproduce my results. I also notice that often, after using Paragon, my GUI boot menu is replaced with a text boot menu (one that sometimes does not recognize the Surface Type keyboard too, at that).

 

The problem is very erratic. For instance, I could clone my existing boot partition into a few copies for testing my full disk compression solutions. These seem to work fine. There are no boot menu delays or boot problems; only perhaps a text mode boot menu instead of the GUI boot menu. The problems only arise with more esoteric techniques, such as VHD boot and WIMBoot.

 

I have used Erwan's CloneDisk to re-create my MFT and Partition boot codes for NT6. I have attempted to reinstall a virgin copy of Windows, exported the BCD store, and re-imported it to the affected system in further efforts to fix the problem. Nothing seems to have had any effect.

 

Right now I am looking for a step-by-step way to completely re-initialize the hidden boot partitions, together with the BCD store, that are typically found on an UEFI system. Could anybody provide a method to do this? Once they are brand-new, then I could go ahead and simply update my BCD with a device partition=C: and osdevice partition=C: to hook it up to my live system.

 

Or if there's any other suggestions forthcoming, I'd appreciate them very much. This is a very pesky and unnerving issue which has been blocking my work for a very long time now.

 

Does anybody know if there's some hidden code on the Surface Pro 2, such as firmware or whatever else, that might also be interfering with the boot process?



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 June 2014 - 02:41 PM

I thought that those issues had been *somehow* solved here:

http://www.msfn.org/...with-junctions/

 

In any case nothing prevents you from completely wipe the hard disk (or SSD/whatever) and start from scratch, still, as you were told earlier, the Surface (or Surface 2) is the least suitable piece of hardware you can find to experiment with (because it is crippled in more than one way) but that should not justify the "erratic" behaviours you now describe.

 

I will repeat how you should NEVER trust *any* of the *automagical* tools such as Paragon Hard Disk Manager or Macrium Reflect (which are good apps by themselves, mind you, but that may "decide" to do somethign slightly different than what expected) and ONLY trust "basic" tools such as dd or the DSFOK (or Clonedisk) for doing 1:1, forensic sound images (and do these "offline").

 

Two very relevant (even if they might not seem so at first sight) questions for you:

 

  1. Why can't you get your hands on a "real" system,  desktop, where you can easily exchange/remove/replace hard disks?
  2. Why, before working on real systems you do not test thoroughly in a VM setup?

 

:duff:

Wonko



#3 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 24 June 2014 - 02:50 PM

Not really - this coincided with me getting the new system, and its pre-infected state. After that point things got kind of complicated at MSFN, and I had to perform some redactions on that thread.

 

Can you elaborate on the ways in which the Surface Pro 2 is crippled? That might explain some of the strange behavior I have been seeing.

 

I should perhaps test thoroughly on a VM setup too, but I'd really like to get to the bottom of this issue, without having to migrate my current development environment manually somewhere else. That is such an incredible pain and would take weeks to get everything set up properly and working.

 

A forensic clone image also raises its own breed of problems; one probably needs to fix up the registry boot paths etc. I could handle those all the same; however keep in mind that my system (and probably the backups too) have already been corrupted as-is; so it might be a bit late for forensics.

 

What I was asking (and never got a response on) at the MSFN thread, and what I'm asking here, is just a way to rebuild from scratch the UEFI partitions that precede my actual C: partition, without losing the contents of my C: partition.

 

That is really all I'm interested in at this stage.

 

If anybody could oblige, I'd be very thankful. I've got nothing but my product to offer in return, and that's what got me into trouble at MSFN in the first place; so I'm averse of repeating that offer here, although in my heart I would love to.



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 June 2014 - 07:16 PM

Not really - this coincided with me getting the new system, and its pre-infected state. After that point things got kind of complicated at MSFN, and I had to perform some redactions on that thread.

Sure, but that has nothing to do with the actual issues.
 

Can you elaborate on the ways in which the Surface Pro 2 is crippled? That might explain some of the strange behavior I have been seeing.

Anything *UEFI* based is by itself "crippled", AFAIK the Surface (and Surface 2) have a number of "features" that are peculiar to the hardware, but more than that (the hints/voices about them may well be some kind of Urban Legend), and more generally, the items involved in the process are 4 (four):
  • the stupid UEFI
  • the stupid OS you are dealing with (Windows 8.1 64 bit)
  • the "crazy" - no offence intended :) - (and not really till now documented/explained in detail) experiments with VHD's or whatever you are doing on it
  • the particular (and particularly stupid)  UEFI implementation of the Surface 2 Pro and/or other "queer" specific quirk of the specific hardware
since I presume that the first three are not up to debate/negotiable, I hoped that we could at least take the last variable out of the equation.

 

I should perhaps test thoroughly on a VM setup too, but I'd really like to get to the bottom of this issue, without having to migrate my current development environment manually somewhere else. That is such an incredible pain and would take weeks to get everything set up properly and working.
 
A forensic clone image also raises its own breed of problems; one probably needs to fix up the registry boot paths etc. I could handle those all the same; however keep in mind that my system (and probably the backups too) have already been corrupted as-is; so it might be a bit late for forensics.
 
What I was asking (and never got a response on) at the MSFN thread, and what I'm asking here, is just a way to rebuild from scratch the UEFI partitions that precede my actual C: partition, without losing the contents of my C: partition.
 
That is really all I'm interested in at this stage.

I understand that, but still it is not IMHO the right approach, as since you have a problem of unknown nature there is nothing even hinting that the issue is there (and not in the contents of your C:\ drive or somewhere else), in this cases starting from scratch is the suggested approach (that of course you are perfectly free to decide to not follow).
 

If anybody could oblige, I'd be very thankful. I've got nothing but my product to offer in return, and that's what got me into trouble at MSFN in the first place; so I'm averse of repeating that offer here, although in my heart I would love to.

Well, at least you shouldn't re-iterate it to me, as you already know how I would decline it.
JFYI ;):
http://reboot.pro/to...-all-the-bytes/


:duff:
Wonko

#5 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 24 June 2014 - 10:07 PM

Oh didn't realize you were Jaclaz :)

 

Unfortunately #1 is beyond my control. It is appearing on more and more systems.

 

#2 is also non-negotiable. I am trying to build something on top of WIMBoot, which is only available with 8.1 x64.

 

#3 may be negotiable. My goal is to have to work around my customers needing to create a bootable Windows PE on a USB and fiddling with having to get that to work. My product is designed for non sophisticated consumers and should work like a Mac - just one click, and off you go. So anyways, I figured, I can go ahead and use VHD boot, to boot WinPE off of the boot menu directly, instead of asking the customer to have to do something even mildly complicated.

 

So for #3: If you can get me steps to create a WinPE instance on a VHD which works with VHD boot and actually supports 8.1 in both UEFI and BIOS modes from a single VHD, that'd be super. If that's not possible, two different VHDs - one for each. Would still be nice. If that's not possible, further ideas on how to implement #3 would be most welcome. And oh, did I mention I also need to support both x86 and AMD64?

 

On #4...I cannot start from scratch...let's just take this as a given. If you want me to upload the contents of my partitions before C:, I can do that. I don't think I could upload my C: partition. I really doubt anything on C: could be interfering with the boot process.

 

Also, I understand you disagree with the approach, but again, it would be superb if I could have some instructions to diagnose and fix the issue. The problem is, some customers are sure to be affected by this malady as well. It will be hard for me to explain to them "oh you'll need to wait for 30 minutes before your computer boots - don't worry, this is normal." So my insistence on fixing my current setup stems, at least partially, from this concern as well.



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 June 2014 - 08:50 AM

So, the VHD booting is an unneeded complication when the scope is to create a PE on a USB stick? :w00t:
And it is used to have an added booting entry in the \boot\BCD (as opposed to change boot order ot press F12 whatever when booting)? :dubbio:

I don't know :unsure:, adding a "permanent" boot entry for an OS residing on a removable drive (i.e. temporary) sounds so wrong in theory that I would not be surprised at all if it created issues in practice.


What is the actual goal?
Have a PE 5.1 on a USB stick?

:duff:
Wonko

#7 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 25 June 2014 - 10:38 AM

Nope, you misunderstand...the goal is for the end-user to have to avoid:

 

1) Finding a USB stick

2) Installing PE on there

3) Booting from that USB stick (having to change BIOS settings, etc.)

 

If, instead, I can prepare a VHD file with that same PE and my app, and then bcdedit that as the default OS, and then reboot - this will be a perfect user experience. The user just clicks OK OK OK and then they're in my app, running from PE; my app of course before restarting PE and relinquishing control reverts back to the main boot OS on bcdedit.

 

At least that's the idea, but in practice, this is insanely difficult. So I hope I can find some instructions which will speed me on my way, as opposed to questioning the why and how...



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 June 2014 - 11:31 AM

If, instead, I can prepare a VHD file with that same PE and my app, and then bcdedit that as the default OS, and then reboot - this will be a perfect user experience. The user just clicks OK OK OK and then they're in my app, running from PE; my app of course before restarting PE and relinquishing control reverts back to the main boot OS on bcdedit.
 
At least that's the idea, but in practice, this is insanely difficult. So I hope I can find some instructions which will speed me on my way, as opposed to questioning the why and how...

The point here is still where the actual PE files (or the .vhd containing them) will be stored (i.e. on internal hard disk or on external USB stick/whatever), but actually in practice it is also illegal to redistribute a pre-made PE, without a specific redistribution agreement with MS, so you are back at step one.

Additionally AFAIK MS has also revoked the (very few) licenses for redistribution of PE based environments that were released, see this seemingly unrelated thread:
http://www.forensicf...r=asc/start=27/

About the questioning the why and how, I can understand how you don't like it, but if you fail to provide the info about your goals, it is improbable that someone may help you in reaching them, and - as often happen - you risk to be slipping on a chocolate covered banana:
http://homepage.ntlw...red-banana.html

:duff:
Wonko
  • Tripredacus likes this

#9 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 25 June 2014 - 11:36 AM

I know I can count on you to remind me of the legal technicalities :)

 

How do companies like Paragon and Macrium distribute PE? Do they acquire a special license from Microsoft?

 

I wonder if it might be possible to build a PE using only the files already installed on an end-user system? The only issue would be building a virgin registry database, I suppose.

 

Once the VHD is ready, it can be stored at c:\. And then VHD booting via device vhd=[c:]\myvhd.vhd etc. At least that's what it says in the "manual". In practice, one gets to experience the sorts of issues I have reported.

 

So I need someone with experience around these kinds of complications to help out. In other words, I'm not really looking for legal roadblock construction, or other sort of non-constructive feedback at this time. For everything I've done, there's been at least 10 times more people who've told me "you can't do it", so I've learned not to attribute much credence to the naysayers over time - for whatever reason.



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 June 2014 - 11:39 AM

Sorry, we were cross-posting (I was editing previous post while you were replying), I added some references to my previous post.

:duff:
Wonko

#11 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 25 June 2014 - 11:50 AM

No problem, I still don't see anything useful there though.

 

You've just linked to another roadblock as far as I can tell.

 

I'm happy to repeat again that there's companies doing this in production, today.

 

I welcome constructive posts as requested earlier. I will not respond to naysaying posts moving forward in the interests of time.



#12 paraglider

paraglider

    Gold Member

  • .script developer
  • 1743 posts
  • Location:NC,USA
  •  
    United States

Posted 25 June 2014 - 12:34 PM

Paragon no longer redistributes PE. Instead they provide a builder application that builds a PE from an installed WAIK.



#13 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 25 June 2014 - 01:16 PM

Macrium appears to download some WAIK components and builds PE. This is similar to how my products open source updates currently work. I am sure this issue will be resolved one way or the other. Microsoft aren't very hostile towards people who build software on their platform.

 

The real challenge here is addressing the technicalities of UEFI, BIOS, x86, and x64 booting from VHD.

 

And before that, installing PE onto a VHD. This is more challenging and even Microsoft docs are contradictory in the steps they indicate.



#14 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 June 2014 - 03:41 PM

Point is (have you missed it? :unsure:) that booting a .vhd is your idea on how to boot a PE, and not necessarily a "smart" one or the "best" one or the "only one".

Anyway, I will refrain from further posting about roadblocks, for fear :ph34r: that you will not reply to them .

As well, since my posts may actually (accidentally or "by design" :w00t:) contain "non-constructive" or "naysaying" parts, I will happily refrain from posting at all, yet another SEP.

Have fun. :)

 

:bye: 

:duff:
Wonko



#15 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 25 June 2014 - 06:11 PM

The real challenge here is addressing the technicalities of UEFI, BIOS, x86, and x64 booting from VHD.

And before that, installing PE onto a VHD. This is more challenging and even Microsoft docs are contradictory in the steps they indicate.

I personally see no advantage in installing PE to a VHD. WinPE is usually booted from a .wim file. This is a container file using a compressed file system - the compression ratio appears efficient. Alternatively it's possible to unpack the contents of boot.wim into a .vhd file - however you will lose the benefits of compression. One advantage of using a .vhd file is lower RAM requirements.

The boot files will still be external to the file format you use - irrespective of whether you use a .wim file (my personal recommendation) or a .vhd file. If a .wim file is used, then the steps for adding a boot entry to an existing BCD store are well documented.

In regards to creating winPE from an installed OS - this is possible, but is not easy to script. Check out erwan.l's QuickPE in the download section. The difficulty in scripting this method is the semi random appearing setups used by OEM's - basically if WinRE is not accessible from the running OS (e.g. it's in a seperate (hidden) recovery partition) then it's going to be hard to automate this process.

Regards,

Misty

P.s. Just for the record - in my opinion Wonko/Jaclaz is a great lateral thinker and has come up with many a solution - saying you can't legally do it is very different to saying it can't be done. As you make references to customers you should perhaps take note of his views on the legalities of your approach or you run the risk of having to recall your product.

#16 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 25 June 2014 - 07:04 PM

And before that, installing PE onto a VHD.

Which VHD contents do you use so far? Do you use VHD PE?

Back then a Win 7 flat file VHD PE was possible.
http://reboot.pro/to...ed/#entry131133
A Win 8 flat file VHD PE should be possible too.

I've no solution to combine UEFI and RAM loaded PE inside a VHD.

As for BIOS and UEFI boot: a wim file is recommended

Be aware about EFI NVRAM settings.
http://msdn.microsof...e/ff542268.aspx
http://technet.micro...y/cc749510.aspx
Delete obsolete entries.

To view entries
bcdedit /enum firmware

To delete all entries.
Howver kids don't do this at home, this deletes OEM specific entries too
bcdedit /deletevalue {fwbootmgr} displayorder 


Expect insane UEFI behaviour at real hardware.
I remember a strange machine at Windows 8 GPT/EFI installed:
Boot default setting at UEFI mode: Windows 8 hangs at boot
Boot setting at automatic: BIOS first / UEFI mode next: Windows 8 does boot.
No, I've no explanation.

Do you have some testing Surface Pro 2? Do you mind to sacrifice one?

#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 June 2014 - 09:30 PM

Waiter, come taste the soup.... ;)

 

 

Point is (have you missed it? :unsure:) that booting a .vhd is your idea on how to boot a PE, and not necessarily a "smart" one or the "best" one or the "only one".

 

 

I personally see no advantage in installing PE to a VHD. WinPE is usually booted from a .wim file. This is a container file using a compressed file system - the compression ratio appears efficient.

 

Ah-ha! :smiling9:

 

http://www.imdb.com/...?item=qt1099763

 

:duff:

Wonko



#18 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 25 June 2014 - 09:53 PM

Jaclaz, you know I love you, right? :wub:

 

cdob, I absolutely have a sacrificial Surface Pro 2. And I can hook you up with full TeamViewer access. I want to see this sorted! Just hit me up if you feel like TeamView'ing into the sacrificial Surface Pro 2.

 

I've uploaded my output to www.zipmagic.co/output.txt - let me know if this provides any clues? [wasn't able to paste in here or attach a file - I'll blame retarded IE software for that]

 

misty, with all due to respect to Jaclaz, let's humor the possibility that there might be something we can do. That's what the spirit of hacking is all about, no? All I want is a consumer friendly approach to booting a system in WinPE without requiring an external USB drive and BIOS/UEFI setting override. There's got to be a way, at least where there's a will :lol:



#19 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 26 June 2014 - 07:18 AM

...All I want is a consumer friendly approach to booting a system in WinPE without requiring an external USB drive and BIOS/UEFI setting override...

How about this approach -
  • Download a precompiled boot.wim - legally from Microsoft (using the ADK download - if you know which .cab file it's contained in and the url then this is simple to automate).
  • Download boot.sdi if it's also required (locate the relevant ADK .cab file and this is also simple to automate).
  • Add the required settings to the BCD store.
  • Job done
Unfortunately there is no one size fits all approach. Using the precompiled boot.wim from the ADK download simplifies a number of the steps and ensures that you have a standard core to build on. Where it gets complicated is the multitude of different approaches used by OEM's and tinkerers such as myself.

Take my own setup for example. Running bcdedit.exe /enum results in the following output -
C:\Windows\system32>bcdedit /enum
The boot configuration data store could not be opened.
The volume for a file has been externally altered so that the opened file is no
longer valid.
This is due to my use of a third party bootloader which is running from a dedicated boot partition (the active partition). When I set the windows partition (this is completely self contained and also has the OS boot files and BCD store) as active the BCD store can be accessed without difficulty. So in my case you would need to locate the BCD store manually and add the entries to this store.

In regards to customising WinPE - no problem - just use the excellent wimlib. There's no need to extract the contents to a .vhd file for Flat Booting WinPE - simply use wimlib to inject the required files into boot.wim and you have a customised WinPE. If you need to include registry settings then simply use wimlib to extract the relevant hive(s) - mount the hive(s) and add your settings and unmount the hive(s) - then inject the edited hive(s) back into boot.wim.

Good luck.

Regards,

Misty

P.s. Licensing restrictions still apply - WinPE is limited to certain uses.

#20 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 26 June 2014 - 09:24 AM

To be honest, that is an excellent approach; but I have come under heavy fire for doing something very similar with open source updates that are consumed by my product - except there, I was not downloading from Microsoft, but from some other third parties. Jaclaz, actually, in this instance, I *would* like to ask you for your legal opinion :)

 

Where the BCD store cannot be found, I will simply ask the consumer to do things manually (as if they mangled their BCD store, they'd surely be able to do those things manually anyways). I also do plan to offer a "create USB drive" feature - but that'll be just a nice to have feature, and not the main workhorse.

 

This is truly an interesting new direction; I also like being able to customize the WIM through WIMLIB very much - I'll just inject my app and the WIMLIB DLLs and bingo!

 

What are the BCD commands to configure a WIM file for boot? Are they the same as their VHD counterparts?

 

Last but not least, does the ADK contain a Windows 8.1 Update 1 WIM? Updating Windows PE 5.0 to 5.1 just so it contains the Windows 8.1 Update 1 has been no trivial task (and the makepe commands that ship with the latest ADK actually do NOT serve the Windows 8.1 Update 1 version - which must still be manually applied).



#21 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 June 2014 - 09:46 AM

To be honest, that is an excellent approach; but I have come under heavy fire for doing something very similar with open source updates that are consumed by my product - except there, I was not downloading from Microsoft, but from some other third parties.

You have an interesting ability to slightly misrepresent facts. :w00t:

Of course there was no issue whatsoever in the downloading of trial versions from third parties, the issue was only in failing to provide clear information to the customer, i.e. that those were trials and required a corresponding license for usage after the trial period elapsed, while your tool enables the user to transparently use them "forever", the matter is somehow solved with the new version of the related FAQ:
http://www.zipmagic.co/faq.html#rar
 

Can I add RAR, ACE, or SIT to the list of compression formats?

Yes. When installing MagicRAR, make sure you permit setup to check for open source updates. This will contact the MagicRAR repository at GitHub, which contains some example, open source plug-ins for MagicRAR.

It is important you understand that MagicRAR cannot natively create, extract, or list SIT archives, and it cannot natively compress ACE or RAR archives, due to the licensing restrictions of these proprietary compression formats (MagicRAR can still natively extract or list ACE or RAR archives).

The open source plug-ins for MagicRAR simply interface with a trial DLL (for SIT archives), or trial command line executables (for ACE or RAR archives), allowing you to seamlessly integrate these proprietary archive formats with the broader MagicRAR suite; and more importantly, offering you simple, open-source examples on how to wrap both third party DLLs, and third party EXE files, within the MagicRAR framework as native MagicRAR plug-ins.

While the integration and the user experience is seamless, the EULAs shown by the MagicRAR installer during the open source update phase are binding on your usage of SIT, ACE, and RAR archive functionality within MagicRAR (with the exception of extracting or listing ACE or RAR archives). In other words, you cannot use MagicRAR to circumvent the need to acquire proper licenses for any third party product that a separate EULA has been shown for.

which settles the issue, unlike the earlier version:
https://web.archive....om/faq.html#rar
 

Can I add RAR to the list of compression formats?

Yes. When installing MagicRAR, make sure you permit setup to check for open source updates.


the issue there (beginning from the name of the tool) was only about inducing (by omission) the "average Joe" to believe that he would not need a separate RAR (and/or ACE/SIT) license to have those functionalities after the correspondent trial period given by the actual tool Authors.
 

Jaclaz, actually, in this instance, I *would* like to ask you for your legal opinion :)

Well you cannot have Jaclaz's (let alone Wonko the Sane's :ph34r:) opinions (which are anyway personal opinions and never legal opinions or advice) at your whims, they usually come motu proprio and semi-randomly (often in the exact moment when you are not expecting one of them) :smiling9:


:duff:
Wonko



#22 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 26 June 2014 - 09:52 AM

Not quite. You never got to connect to the online repo through your VM (sometimes happens with GitHub), but the third party EULA's are clearly shown during the open source update install process anyways. While the FAQ was indeed misleading (which is why I corrected it), this was an oversight compared to the in-your-face experience found in the installer, which clearly showed, and still shows, the third party EULAs together with their binding clauses.

 

Now let us not beat a dead horse or hijack another thread :) But the technique appears to be the same here, with only the party being downloaded from being different - Microsoft. So since you have alleged that I allow indefinite use of some third party software via this technique (even when that software is perpetually non-expiring itself, as I indicated earlier), can you help me understand why the same argument would not in principle apply to Microsoft software as well?


Edited by simonking, 26 June 2014 - 09:54 AM.


#23 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 June 2014 - 11:31 AM

The WAIK (actually ADK):

http://www.microsoft...s.aspx?id=39982

 should have a license.

 

Read it.

 

It prohibits redistribution by third parties and poses a number of limits to it's usage, but it is not a "trial" and has not a "trial period".

 

As long as you don't redistribute it and comply with the other requirements of it's EULA, you are fine.

 

You can provide a tool/whatever that makes it easier the downloading of the ADK from MS servers (that of course are perfectly free to change at any time the address and the availability of the ADK), i.e. it is the final user (helped by your tool) that downloads the freely available ADK directly from MS.

As well the final user is responsible for it's use within the License.

 

The moment you redistribute the ADK (or parts of it) you are breaking that same license (to MS there is no difference between you and the final user, you are a "final user" the moment you download the ADK and you are bound to not redistribute it).

 

If in any way you misrepresent what your tool does or overall induce your final user to break the MS EULA, this might be a different issue.

 

Just like the previous issue which - again - was about the lack of information that you provided on the website to your final user , who might have been induced to buy a license for your tool believing that with it he/she could have indefinitely the RAR/ACE/SIT "full" functionalities.

 

And, of course, it would make even more sense to NOT use the ADK at all and create the PE from the locally available files coming from the installed OS.

 

 

:duff:

Wonko



#24 misty

misty

    Gold Member

  • Developer
  • 1066 posts
  •  
    United Kingdom

Posted 26 June 2014 - 06:23 PM

What are the BCD commands to configure a WIM file for boot? Are they the same as their VHD counterparts?

Depends on whether it's booted in UEFI or BIOS mode. For UEFI, try the following batch -
@echo off
::___________________________________
ECHO Creating ramdisksdidevice entry...
for /f "tokens=2 delims={}" %%g in ('bcdedit.exe /create /device') do set ramdisk={%%g} 
bcdedit.exe /set %ramdisk% ramdisksdidevice boot
bcdedit.exe /set %ramdisk% ramdisksdipath \boot\boot.sdi 

Echo Adding RAM Boot WinPE entry...
for /f "tokens=2 delims={}" %%g in ('bcdedit.exe /create /application osloader') do set GUID={%%g}
bcdedit.exe /set %GUID% systemroot \Windows
bcdedit.exe /set %GUID% detecthal Yes
bcdedit.exe /set %GUID% winpe Yes
bcdedit.exe /set %GUID% osdevice ramdisk=[boot]\sources\boot.wim,%ramdisk%
bcdedit.exe /set %GUID% device ramdisk=[boot]\sources\boot.wim,%ramdisk%
bcdedit.exe /set %GUID% path \windows\system32\winload.efi
bcdedit.exe /set %GUID% description "Windows PE RAMBoot (UEFI)"
bcdedit.exe /displayorder %guid% /addlast
echo.
endlocal
pause
For BIOS, try the following batch -
@echo off
::___________________________________
ECHO Creating ramdisksdidevice entry...
for /f "tokens=2 delims={}" %%g in ('bcdedit.exe /create /device') do set ramdisk={%%g} 
bcdedit.exe /set %ramdisk% ramdisksdidevice boot
bcdedit.exe /set %ramdisk% ramdisksdipath \boot\boot.sdi 

Echo Adding RAM Boot WinPE entry...
for /f "tokens=2 delims={}" %%g in ('bcdedit.exe /create /application osloader') do set GUID={%%g}
bcdedit.exe /set %GUID% systemroot \Windows
bcdedit.exe /set %GUID% detecthal Yes
bcdedit.exe /set %GUID% winpe Yes
bcdedit.exe /set %GUID% osdevice ramdisk=[boot]\sources\boot.wim,%ramdisk%
bcdedit.exe /set %GUID% device ramdisk=[boot]\sources\boot.wim,%ramdisk%
bcdedit.exe /set %GUID% path \windows\system32\winload.exe
bcdedit.exe /set %GUID% description "Windows PE RAMBoot (BIOS)"
bcdedit.exe /displayorder %guid% /addlast
echo.
endlocal
pause
Please note that I have not tested either of these batches - they have been adapted from working scripts I use and should be ok. The only difference between UEFI and BIOS is the path entry (\windows\system32\winload.efi for UEFI and \windows\system32\winload.exe for BIOS). You may be able to boot some versions of WinPE without actually specifying the path in the BCD entry - you'll need to confirm this yourself though. You may well need to change the paths to boot.sdi and boot.wim.

 

Last but not least, does the ADK contain a Windows 8.1 Update 1 WIM? Updating Windows PE 5.0 to 5.1 just so it contains the Windows 8.1 Update 1 has been no trivial task (and the makepe commands that ship with the latest ADK actually do NOT serve the Windows 8.1 Update 1 version - which must still be manually applied).

The last time I downloaded the ADK it contained WinPE 5.0. Not sure why you require WinPE 5.1 as wimboot appears to be the only difference between WinPE 5.0 / WinPE 5.1.

 

And, of course, it would make even more sense to NOT use the ADK at all and create the PE from the locally available files coming from the installed OS.

If you could guarantee that winre.wim has not been messed up by the OEM and is in a standard and accessible location then I would agree. Unfortunately this is not likely to be the case. I am not aware of any way to build WinPE from scratch from the files contained in an installed OS - some of the required files just aren't contained in a standard Windows installation. The boot.wim and winre.wim files included with Windows installation media can both be customised - sadly OEM's don't always include installation media.

Regards,

Misty

#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 June 2014 - 07:09 PM

I am not aware of any way to build WinPE from scratch from the files contained in an installed OS - some of the required files just aren't contained in a standard Windows installation. The boot.wim and winre.wim files included with Windows installation media can both be customised - sadly OEM's don't always include installation media.

Doesn't recoverydrive.exe work the same in 8.1 as it did in 8.0? :dubbio:

Isn't it "mandatory"?:unsure:

http://reboot.pro/to...drive/?p=169870

 

The fact that everyone is using the ADK and/or the boot.wim/install.wim/winre.wim/whatever does not really mean that it is the "only" way.

 

I have no idea on how exactly the recoverydrive.exe works, which files uses as "source" and what (the heck) it stupidly puts on the stupid USB stick, but it shouldn't be that difficult to find out, if anyone with a 8.1 install is willing to experiment and report.

 

Providing a list of the files that you believe are missing in an installed OS could be another (little) step forward.

 

:duff:

Wonko 


  • misty likes this




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users