Jump to content











Photo
- - - - -

Booting WinPE from hard disk and motherboard failure


  • Please log in to reply
37 replies to this topic

#1 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 08 December 2021 - 05:08 PM

Hello,

 

I am experiencing a very strange and painful case. I have a batch file adding Win10XPE to the boot menu of Windows 10. The purpose is to boot from a .wim file extracted from Win10XPE after restarting the computer. Generally, this method works fine but after restart , some computers failed - the motherboards went broken. This happened three times.  The .wim file cannot harm the hardware but I suspect it's the updated BCD store damaging the computers. Anyone who experienced such a weird case?

 

All the failed systems are UEFI and secure boot is enabled.

 

The batch file :

 

bcdedit /export C:\Bcdbackup.bin
 
bcdedit /create {ramdiskoptions} /d "Win10XPE-64bit"
 
bcdedit /set {ramdiskoptions} ramdisksdidevice partition=C:
 
bcdedit /set {ramdiskoptions} ramdisksdipath \winpe\boot\boot.sdi
 
FOR /F "tokens=3" %%a in ('bcdedit -create /d "Win10XPE-64bit" /application OSLOADER') do SET GUID=%%a
 
echo %GUID% > C:\Win10PE-GUID.txt
 
echo bcdedit /delete %GUID% > C:\DelWin10PE.bat
 
bcdedit /set %GUID% device ramdisk=[C:]\winpe\sources\boot.wim,{ramdiskoptions}
 
bcdedit /set %GUID% path \windows\system32\winload.efi
 
bcdedit /set %GUID% osdevice ramdisk=[C:]\winpe\sources\boot.wim,{ramdiskoptions}
 
bcdedit /set %GUID% systemroot \windows
 
bcdedit /set %GUID% winpe yes
 
bcdedit /set %GUID% detecthal yes
 
REM bcdedit /displayorder %GUID% /addlast
 
bcdedit /bootsequence %GUID%


#2 alacran

alacran

    Gold Member

  • .script developer
  • 2386 posts
  •  
    Mexico

Posted 10 December 2021 - 08:04 AM

At first seen it seem your Batch file should not be the cause of the problem, only comment I have is the following.

 

To be more precise for a PE.wim or a boot.wim file, the BCD entries target are:

 

On the Boot\BCD the bootfile target is: \windows\system32\boot\winload.exe for MBR/CSM booting.
On the EFI\Microsoft\Boot\BCD the bootfile target is: \windows\system32\boot\winload.efi for UEFI booting

 

In the future better use UEFI_MULTI program, made by our forum fellow wimb.

 

Just run it from a Win10x64 OS or PE, follow the  instructions, (on the very bottom part of its small window), and it will make automatically all entries required to boot a PE or a VHD file from a internal or external drive, valid for MBR/CSM and UEFI.

 

alacran



#3 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 10 December 2021 - 06:25 PM

Hi alacran,

 

I am working on UEFI systems. Comparing the same file found in different locations :

C:\>fc C:\Windows\System32\Boot\winload.efi C:\Windows\System32\winload.efi
Comparing files C:\WINDOWS\SYSTEM32\BOOT\winload.efi and \WINDOWS\SYSTEM32\WINLOAD.EFI
FC: no differences encountered

The result of the test above in the WinPE environment is the same. The batch file is harmless. What I suspect is some Windows updates disturbing the BCD records as the duty of the batch file is only to update the BCD file :

"\Efi\Microsoft\Boot\BCD"

A member of the Microsoft forum reported to use the same method to boot WinPE from RAM. I experienced similar symptoms before the motherboard failure :

 

Upon restarting, when the system boots I hear the fans start but then they stop following a few seconds of silence.
The system then starts again with the fans at full speed it sounds like but nothing is displayed on the monitor.
I then have to power it off 1 or 2 times to let the normal boot procedure kick in so I can get back into Windows.

 

 

https://docs.microso...e-from-ram.html

 

The same start and stop sequence followed by silence indicating the motherboard going kaput.

 

Booting from a USB stick or from LAN does not pose any problem. Both of them are good to boot Win10XPE.

 

Here is another source mentioning about similar BCD handling method :

 

https://docs.microso...265131(v=ws.10)

 

My intention is to switch to UEFI grub4dos, this will require the disablement of secure boot. In my tests, I had good results using this tool.



#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 10 December 2021 - 06:45 PM

Vortexx, it may or may not be relevant, but you have no way to know.

 

If your batch uses:

bcdedit /set %GUID% path \windows\system32\winload.efi

but (according to Alacran who has some experience in the specific matter) it should use:

bcdedit /set %GUID% path \windows\system32\boot\winload.efi

 

It is not by fc-ing the two files and finding them identical you are going to prove or disprove anything.

 

For all we know the contents of the BCD hive that the path parameter of BCEdit accesses could be read by anything during the boot process and checked *like*

"if before winload.efi there is \Boot\ then proceed, otherwise throw a fit"

or you could put winload.efi into D:\myEFI\ and have it still work correctly, we simply don't know.

 

:duff:

Wonko


  • alacran likes this

#5 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 10 December 2021 - 06:56 PM

Hi Wonko,
 
It's Microsoft mentioning about the path of the .efi file :
 
bcdedit -store S:\EFI\Microsoft\Boot\BCD -set {Default} path \windows\system32\winload.efi
 
 
I inserted the statement "boot" into my batch file, it boots successfully WinPE on my old computer ( old BIOS and not UEFI )
 
I cannot afford the loss of another motheboard so probably better to switch to UEFI grub4dos. It's a an expensive experiment at least for me. I can tell that with or without the word "boot" in the path , the Windows loader can find the .wim file to load.


#6 noel

noel

    Frequent Member

  • Advanced user
  • 158 posts
  • Location:nantes
  •  
    France

Posted 10 December 2021 - 08:26 PM

Hi vortex,
in the first link you gave, i see :
"What does the .sdi do and what is it for?"

Your batch works and modifies bcd on many computers and they start correctly. Ok

But your script don't describe the added files .

As i said iin the "other site" where you posted, please describe the added files and especially the directory containing boot.sdi.

It is possible that this boot.sdi file was missing on the failed 3 ( did you check it before boot ? )

Noel



#7 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 10 December 2021 - 08:57 PM

Salut Noel,

 

About boot.sdi :

 

https://docs.microso...771845(v=ws.10)

 

Here is the list of the files extracted from the .iso file with 7-Zip :

 

C:\>dir /b /s C:\winpe
 
C:\winpe\boot
C:\winpe\sources
C:\winpe\boot\bcd
C:\winpe\boot\bcd.LOG
C:\winpe\boot\bcd.LOG1
C:\winpe\boot\bcd.LOG2
C:\winpe\boot\boot.sdi
C:\winpe\boot\bootsect.exe
C:\winpe\boot\en-US
C:\winpe\boot\etfsboot.com
C:\winpe\boot\Fonts
C:\winpe\boot\memtest.exe
C:\winpe\boot\en-US\bootmgr.exe.mui
C:\winpe\boot\en-US\bootsect.exe.mui
C:\winpe\boot\en-US\memtest.exe.mui
C:\winpe\boot\Fonts\chs_boot.ttf
C:\winpe\boot\Fonts\cht_boot.ttf
C:\winpe\boot\Fonts\jpn_boot.ttf
C:\winpe\boot\Fonts\kor_boot.ttf
C:\winpe\boot\Fonts\malgunn_boot.ttf
C:\winpe\boot\Fonts\malgun_boot.ttf
C:\winpe\boot\Fonts\meiryon_boot.ttf
C:\winpe\boot\Fonts\meiryo_boot.ttf
C:\winpe\boot\Fonts\msjhn_boot.ttf
C:\winpe\boot\Fonts\msjh_boot.ttf
C:\winpe\boot\Fonts\msyhn_boot.ttf
C:\winpe\boot\Fonts\msyh_boot.ttf
C:\winpe\boot\Fonts\segmono_boot.ttf
C:\winpe\boot\Fonts\segoen_slboot.ttf
C:\winpe\boot\Fonts\segoe_slboot.ttf
C:\winpe\boot\Fonts\wgl4_boot.ttf
C:\winpe\sources\boot.wim


#8 alacran

alacran

    Gold Member

  • .script developer
  • 2386 posts
  •  
    Mexico

Posted 10 December 2021 - 11:10 PM

Hi alacran,

 

I am working on UEFI systems. Comparing the same file found in different locations :

C:\>fc C:\Windows\System32\Boot\winload.efi C:\Windows\System32\winload.efi
Comparing files C:\WINDOWS\SYSTEM32\BOOT\winload.efi and \WINDOWS\SYSTEM32\WINLOAD.EFI
FC: no differences encountered

 

I also made that comparative long time ago and I can assure you even the SHA1 of the two files is the same, but I also found during my experiments on this topic Install Win10XPE_x64 Flat or Compact Mode on VHD , that not always work the same (if using the usual path to boot a full OS, the PC may boot from a PE or not, and don't ask me why, as I don't know the per sure the answer, my theory is it depends of internal code in the Bios), unfortunatelly I didn't mentioned this findings in detail in that topic, just made a strong recommendation to use the right path, as it will work fine always.

 

Just going by the book, extract from a Win10XPE_x64.iso both bcd files (yes usually on WinPE they never use capital letters for them, maybe as a way just to diferenciate from the standard BCD), now run BootIce and open them and you will see the paths I mentioned are exactly the same.

 

But yes, as I said at first seen the path should not be the cause of a MB failure.

 

Let's analyze the info you have, in order to find a possible cause:

 

What have in common the MBs that failed:

 

Same brand

Same model

Same Bios Builder

Builded same year (then Bios are builded in accordance with certain UEFI version)

etc.

 

The UEFI specs allow, and even going further promote that the OEM include certain mini programs specifically designed to run during the very first stages of UEFI boot to realize certain tasks supposedly mainly to improve security/safety/speed of booting process, if one of those UEFI programs went too far and is over protecting the BCD(s) to not allow/block the boot of unauthorized/wrong code if detected, this may be the also cause of the failures, so IMHO the Bios code with or without some additional UEFI program is the biggest suspect in this crime investigation, if possible as an extra precaution it is better always disable Secure Boot before working on the boot process or installing a OS (as an extra safety precaution, just in case), Or better (as I always do) just leave it disabled forever, as it is only good to protect MS pocket, forcing all people/companies that make drivers and programs to pay them to get the certification. It doesn't help to prevent any malware, all malware just laugh about it.

 

But only you know all the full info, and only you can put all pieces togheter, please keep us informed, as this info seems very important for all us here, experimenting very frecuently booting every kind of things.

 

And let me tell you why I recommend you to always use UEFI_BOOT, it is very safe because it DOES NOT use any of those paths to boot a WinPE boot.wim, it just let the Bios + the internal code into the OS boot process to handle the path to the target file.  Basically it saids use this boot.sdi, find following X.wim file and boot from it. Please see attached pictures.

 

NOTE: BootIce is an old program written before Win10, I have found it does not work fine to create 10 PE entries, (my theory is it laks the GUID code for them), but no problem with any OS, or OS into a VHD or older PE(s), anyway it is very useful to edit 10 PE entries once they exists.

Hope this info was of any help.

 

alacran

Attached Thumbnails

  • Booting a PE.png
  • Booting a PE-2.png


#9 alacran

alacran

    Gold Member

  • .script developer
  • 2386 posts
  •  
    Mexico

Posted 11 December 2021 - 01:30 AM

 

Salut Noel,

 

About boot.sdi :

 

https://docs.microso...771845(v=ws.10)

 

Here is the list of the files extracted from the .iso file with 7-Zip :

C:\>dir /b /s C:\winpe
 
C:\winpe\boot
C:\winpe\sources
C:\winpe\boot\bcd
C:\winpe\boot\bcd.LOG
C:\winpe\boot\bcd.LOG1
C:\winpe\boot\bcd.LOG2
C:\winpe\boot\boot.sdi
C:\winpe\boot\bootsect.exe
C:\winpe\boot\en-US
C:\winpe\boot\etfsboot.com
C:\winpe\boot\Fonts
C:\winpe\boot\memtest.exe
C:\winpe\boot\en-US\bootmgr.exe.mui
C:\winpe\boot\en-US\bootsect.exe.mui
C:\winpe\boot\en-US\memtest.exe.mui
C:\winpe\boot\Fonts\chs_boot.ttf
C:\winpe\boot\Fonts\cht_boot.ttf
C:\winpe\boot\Fonts\jpn_boot.ttf
C:\winpe\boot\Fonts\kor_boot.ttf
C:\winpe\boot\Fonts\malgunn_boot.ttf
C:\winpe\boot\Fonts\malgun_boot.ttf
C:\winpe\boot\Fonts\meiryon_boot.ttf
C:\winpe\boot\Fonts\meiryo_boot.ttf
C:\winpe\boot\Fonts\msjhn_boot.ttf
C:\winpe\boot\Fonts\msjh_boot.ttf
C:\winpe\boot\Fonts\msyhn_boot.ttf
C:\winpe\boot\Fonts\msyh_boot.ttf
C:\winpe\boot\Fonts\segmono_boot.ttf
C:\winpe\boot\Fonts\segoen_slboot.ttf
C:\winpe\boot\Fonts\segoe_slboot.ttf
C:\winpe\boot\Fonts\wgl4_boot.ttf
C:\winpe\sources\boot.wim

 

 

What a waste of space my friend, to boot a PE from a internal or external drive you only need boot.sdi + boot.wim files, all other required files and folders are already in your EFI partition some in the root and some into EFI folder, in your case of UEFI booting, and same apply in case of MBR/CSM booting but here the folder name is Boot, and usually the boot.sdi file is already into the folder too.

 

Of course it is a good practice to rename the boot.wim file, and obviously fully required if you have more than one.

 

alacran



#10 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 11 December 2021 - 09:56 AM

Hi alacran,

 

Thanks for your help. I should mention in my first posting in this thread, I am performing remote installations \ maintenance of laptops\desktops located in a remote office. I added TightVNC to my WinPE build  to access the computers in the remote branch. Loggining in to Windows, it's sufficient to run the batch updating the BCD records to boot Win10XPE after restarting the computers. You can imagine the consequences of another motherboard failing, the time for the replacement of the failed part and me losing credits after such incidents. Luckly, two of the computers are under warranty. One of them returned back and the other one visiting the repair shop waiting for the hardware replacement. I can even install and backup Windows over a VPN connection with the procedure I described above.

 

The problem is that my chances to request assistance from the remote office is modest and I need to rely on a simple method - keep things simple as much as possible - to do all the job. This is why I prefer a batch file.

 

Two of the failing computers are identical, same brand, same model number etc.

 

It's true that only boot.sdi in the boot folder does the job but this folder occupies only 17.1 Mb, a tiny fraction of the hard drive, not a serious waste of space as you might think.

 

Extracting the BCD file from the wim file, BootIce reflects the complete path you mentioned, it's \windows\system32\boot. We agree that the path pointing boot.sdi should not be the cause of all the trouble.

 

I never used UEFI_BOOT. Does it touch the BCD record of the computer? I think that UEFI grub4dos will be safer as it does not have to manipulate the settings of Windows, no any modification of BCD etc.

 

I am also doing the sysprep operation to distrubute the same Windows setup ( .wim archive including the preinstalled applications ) on identical computer models. I am not a novice in the area of building and using WinPEs, I even used BartPE long years ago.

 

About your paragraph regarding UEFI, all is true as the high-tech companies are the sole winners. UEFI, BCD etc all of those inventions are unnecessarly complicated, the purpose to make more $$$. What about the simplicity of the original UNIX regarding every entitiy as files? Also, every setting going into simple text files.

 

I will try to focus on the experiences with UEFI grub4dos.



#11 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 11 December 2021 - 10:19 AM

the motherboards went broken. 

 

All the failed systems are UEFI and secure boot is enabled.

That's strange. No, I haven't seen this.
 
Can you clarify: the motherboards went broken? 
Is there any boot sign at all? Can you go to UEFI settings and load system defaults?
 
Which motherboards, and which UEFI version went broken?
 
Bcdedit writes UEFI boot settings to NVRAM too.
No bcdedit dosn't write directly, bcdedit asks the UEFI to store boot entry in NVRAM.
The NVRAM storage is limited.
It there are a lot of entries already, there could be a error adding another boot entry.
Maybe there is another error. 
A UEFI reset / removing the CMOS battery may help.

  • wimb likes this

#12 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 11 December 2021 - 10:42 AM

Hi cdob,

 

In two cases, the authorized repair shop reported the failure of the motherboards. You hit the power button and no any response, no any chance to enter the BIOS or boot the system. Well, the third case didn't require the assessment of any repair shop, it was easy to guess the failure of  the motherboard.

 

No bcdedit dosn't write directly, bcdedit asks the UEFI to store boot entry in NVRAM.

 

 

It's the BCD file in the first partition of the computer, the BCD found in the FAT32 partition managed by bcdedit :

\Efi\Microsoft\Boot\BCD


#13 wimb

wimb

    Platinum Member

  • Developer
  • 3607 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 11 December 2021 - 10:58 AM

@Vortex

 

What is the Source of your WinPE and How was it made ?

 

Could it be that the drivers in your WinPE are causing your motherboard failure ?



#14 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 11 December 2021 - 11:13 AM

Hi wimb,

 

It's Win10XPE.iso built from Windows 10 64-bit version 2020 H1. The drivers cannot be the reason of the trouble, the failed computer cannot even boot WinPE.


  • wimb likes this

#15 wimb

wimb

    Platinum Member

  • Developer
  • 3607 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 12 December 2021 - 06:22 AM

It's Win10XPE.iso built from Windows 10 64-bit version 2020 H1. The drivers cannot be the reason of the trouble, the failed computer cannot even boot WinPE.

 

OK

Is ChrisR on GitHub your Source to make Win10XPE Or do you use another Source ?

 

What is your Win10XPE Build Core Configuration 1 Or 2 ?

1. Run All Programs from RAM - means everything OS + Programs is contained in single WIM file

2. Programs are outside WIM file in Programs Folder Searched for on Drive having Tagfile CDUsb.y



#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 December 2021 - 08:49 AM

As always I may be wrong, but yours would be among the few, very rare cases where a software can kill hardware, the so-called "killer poke"

https://en.wikipedia...iki/Killer_poke

but usually (like in 99.99% of cases) the result is not really a permanent damage to the hardware, but rather this (or that) type of "bricking", i.e. for some reasons software/data embedded in the hardware, i.e. firmware (like the BIOS, or UEFI or the adaptive data on hard disk controllers, etc.) becomes corrupted and prevents the hardware from working.

 

As cdob said, with the (stupid) NVRAM it could be a matter of filling it to the brim (and there must be some error in the firmware that doesn't provide for overwriting old entries or doesn't  protect for writing past the end of available space or doesn't update correctly some index structure, etc.), this is the only thing that sounds plausible as other (possible in theory) kinds of firmware corruption can only be triggered by very specific code (nothing that can happen in a "normal" OS booting, and from what you report you are using a rather common setup for your PE booting, and you are using the "official" BCDedit, nothing out of usual).

 

Depending on the specific motherboard it could be possible (non-destructively) to inspect the contents of the BIOS/UEFI firmware and/or re-flash its contents to factory default.

 

ONLY as an example the procedure is used on some Lenovo Thinkpads by BIOS modders:

 

https://www.thinkwik...8xx30_and_up.29

https://www.bios-mod...=74575#pid74575

https://www.chucknem...o-x230-coreboot

 

I don't think that any ordinary (even if "authorized") assistance shop would do this kind of checks/repairs, they most probably apply power, see that it doesn't boot and emit the sentence "motherboard is dead".

 

:duff:

Wonko



#17 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 12 December 2021 - 01:11 PM

Hi Wonko,

 

The repair shop probaly does not spend much efforts for further diagnosis, that's true. Simply, they will replace the faulty part.

 

The worst in my case is that the failed computer cannot be powered on so there is not much things to do at this stage. Two different computer brands demonstrated this failure.



#18 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 12 December 2021 - 01:45 PM

Hi wimb,

 

The source link is ChrisR's GitHub account :

 

https://github.com/ChrisRfr/Win10XPE

 

My Win10XPE Build Core Configuration is option 1 placing all the applications to RAM.


  • wimb likes this

#19 wimb

wimb

    Platinum Member

  • Developer
  • 3607 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 12 December 2021 - 01:50 PM

 

The source link is ChrisR's GitHub account :

 

https://github.com/ChrisRfr/Win10XPE

 

My Win10XPE Build Core Configuration is option 1 placing all the applications to RAM.

 

Thanks for the Info.

 

I use the same and can always use boot.wim for booting 10XPE from RAMDISK without damaging the motherboard.

 

I think it remains very strange that you experienced so many times booting 10XPE is causing motherboard failure.



#20 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 December 2021 - 03:20 PM

Hi Wonko,

 

The repair shop probaly does not spend much efforts for further diagnosis, that's true. Simply, they will replace the faulty part.

 

The worst in my case is that the failed computer cannot be powered on so there is not much things to do at this stage. Two different computer brands demonstrated this failure.

 

Yep, once upon a time, there was the CIH virus:

https://en.wikipedia...computer_virus)

 

Anecdotally, besides the (all in all relatively simple) fat data recovery, at the time I saved quite a few (desktop) boards, if I recall correctly some 8-10 of them (for friends, after self-declared specialized technical assistance laboratories had told them that data was lost and motherboard was dead)  by either hot-swapping the BIOS chip, or in a couple cases, replacing it with a chip taken from a "really dead" motherboard. 

 

:duff:

Wonko



#21 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 12 December 2021 - 03:35 PM

The repair shop probaly does not spend much efforts for further diagnosis, that's true. Simply, they will replace the faulty part.

.
A very strange behaviour, I doubt a general hardware failure still.

 

Given a Laptop, the first idea is to remove and attach the internal battery. 

.
There are manufacturer emergency approaches, e.g. a emergency pin hole reset button
https://support.leno...er-bios-update/

Or  Reset the Embedded Controller and Reset the CMOS 


  • alacran likes this

#22 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 12 December 2021 - 04:17 PM

Hi wimb,

 

Booting the wim file or the iso file is not dangerous. Using a USB stick or Erwan's TinyPXE Server with iPxe does not create any problem. The worst scenarios happens if you use bcdedit to modify the BCD store.


  • wimb likes this

#23 alacran

alacran

    Gold Member

  • .script developer
  • 2386 posts
  •  
    Mexico

Posted 13 December 2021 - 11:29 PM

Can you give us the info of failed MBs?

 

Brand, model, UEFI Bios version and buider. etc.

 

alacran



#24 alacran

alacran

    Gold Member

  • .script developer
  • 2386 posts
  •  
    Mexico

Posted 15 December 2021 - 07:12 AM

JFYI

 

Vortex shared with me by PM the models of the 3 laptop that fail (it seems to me he doesn't want to make public this info), so only thing I can do is respect his decision:

 

2 of them are same model of a well known OEM brand.

1 is a model of a OEM brand unknown for me untill I read his message.  (I wasn't able to get more info about it in this case).

 

For the first two I found they have A LOT of Security management (as they call it) features, in UEFI Bios or as additional UEFI programs + many more as usual software programs.

 

From the full list, of course some of this items work only after the OS is running, but some of them run before the OS is loaded as some are integrated into the UEFI Bios or are UEFI programs, and only thing needed to block the PC is one of them detects an unautorized access to the PC (or as in this case a change in pre-set BCD), to block further boot process.

 

So to me there is no dubt the issue is caused by UEFI Bios settings + additional UEFI programs.

 

Many of this Security management (features) seem to me as a damn exaggeration from the OEM.

 

Hope our fellow Vortex changes his mind, and share with all in the forum the OEM models of the laptops that faill.  Because I really think it is very important to make this info public to avoid more people have same problem.

 

alacran


  • wimb likes this

#25 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 291 posts

Posted 15 December 2021 - 06:45 PM

Hi alacran,

 

I don't know if I am allowed to mention about the brands and models, what's the forum's rule concerning this case?

 

Today, one of those computers ( the lesser-known brand ) returned back to my office. Surprisingly, the computer had no any problems and it worked. It passed all my WinPE booting tests including UEFI grub4dos and my batch file above. I asked my colleague if he plugged the power supply and his reply was affirmative so no drain of battery. Mysteriously, it refused to operate in the remote office. 






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users