:emotion-2:

Do you remember the Dell Update ? Is it the BIOS update? By the way, what is your Dell model number? Ex: Dell Inspiron 3543

Deleted....

Deleted....

Dell models are uniquely identifed with service tags.

Oh great ... now I see the admin removed my tag;  is "Inspiron 3147" legal to post?

AKA Inspiron 11 in the BIOS ( A10 4/22/2016 )

It may be possible that I'm the victim of Malware.  I have NEVER received an automatic

update pushed by Dell to this machine.  A PopUp window merely said an update had

been applied ( no identifier provided ) and I had to reboot.

All of my updates have been applied by searching the Dell site.

- And I have previously reported that the Dell Upd service is broken.

 The check fails because of version checking data that is supposed to be on

 the Dell website, but is missing ... causing the automated update to fail.

I've spent the weekend trying to recover and am really disgusted with the Windows

architecture that centers on the fragile target called "The Registry".

You just can;'t back up a system unless you have a coherent registry,

and it is VERY easy to get the software and the registry out of sync ...

accidently or on purpose by hackers.

So my system is bricked and all of the tricks I know to recover it have failed.

Now I am using Acronis TrueImage to recover the contents of the disk ...

which works ... but has severe limitations.  A backed up partition can be mounted

by Acronis as a drive letter, but it is mounted Read-Only and Windows blocks

access to files in the C:\User\loginid directories.  Oh great.  

And Windows also protects system files from access, even as Administrator.

What I'm trying to figure out with what remains of this broken system

is what commands were issued in it's last gasping moments.

The logs are protected.  I likely need to know files that are in the system,

and can identify them by date modified ... except I cannot access those files.

Another diagnostic attemp was to have Windows Advanced Startup settings

create a boot log.  The boot process fails, but where is the log?

I know the disk is healthy because I can run diagnostics on the drive.

My next step is to build and run a USB image of the Ultimate Boot tool.

It has worked well for me in the past, including running an AV tool

against the non-bootable drive.

" My preference is to use a Restore Point to back out this Dell update ".

:emotion-2:

Why won't you use one of the Restore Points on the system ? You will not lose any data or any other important stuff.  I'd suggest you use it to go back to a earlier time before the issue occurred.

The link below might be helpful to you.

Download Dell Recovery & Restore to a USB drive. Please click on link below:

www.dell.com/.../keyincloud

I suggest you run Linux Live USB to recover data on your system. Please click on the link below and follow instructions. The link is by one of the forum rock stars - natakuc4)

dellwindowsreinstallationguide.com/.../

I have now tried EZRecovery and Ultimate Boot..  The Dell laptop has no CDRom, so I have to create bootable USB media from the product ISO files.  The utilities I use ( suggested by the product owner) do not create a bootable USB that is recognized by the Dell machine.  Both products work correctly on an HP laptop.  Both laptops use EFI safe boot.

Acronis TrueImage USB media is correctly recognized by the Dell laptop and so is the Win10 USB built with Microsoft's media creator.

My next TryIt will be to unpack EZRecovery ISO with 7Zip and then burn that to USB using the Acronis technology.

@LSUFAN51:  Why don't I use Win10 Restore Points?

Because the system has to actually boot Win10 to do that.

I will try to download the Dell Recovery and burn it.  Thanks for that suggestion.

Regarding Linux Live USB.  Recovering my data is not the fundamental problem.

I've already saved partition images with TrueImage.

Unless you opt for "Portable Apps" on Windows ... apps that don't require the Windows

Registry ... restoring application files is not going to work very well.

Did you notice that the builtin recovery mechanisms on the Dell machine did not

diagnose/repair the booting problem.   I can't see where a USB launched version of

the same code will change the result, but I'll certainly try.

And the TrueImage partition images aren't very useful to restore my system because I will just be restoring a broken system.

Finally, I tried to build a Windows Install image on an external SSD and boot from that so I can observe the internal harddisk as a second drive so I can better diagnose the boot failure.

Also noticed there is a stern warning in the BIOS if you try to change the EFI boot options to Legacy.  The claim is this is a destructive action that will corrupt the current image.  I don't know if I believe that or not, but I'm unwilling to change things that will further corrupt the internal disk.

But .... I may try it because I can always restore the system to it's initial broken state from the Acronis images.

By the way, can anyone at Dell confirm that they pushed an update to my system?

If so, what did it change.  Windows 10 will download fixes from sites other than its

own in Win10.  I don't know how they decide which ones are safe.

My Win10 update options are set to "Download but do not install".

I want to control the timing of these updates so I can prepare with a regular backup first.

Excellent.  I've used the Fedora/Rufus recover path before for other platforms.

Thanks for the reminder .... working thru the details now..  The Dell KB article

you referenced is excellent.

The Dell Recovery & Restore KB article confirms that it is ok to disable Secure Boot in the BIOS for the purpose of booting from Legacy USB drives.  It does not destroy the internal drive Win10 install.

But restoring Secure Boot after recovery is required to restore Win10 booting behaviour.

Good to know.  The internal Recovery Inspiron 3147 diagnostic instructions are misleading and incorrectly suggest this is a destructive action.

Quick reply:  I cannot use Win10 Restore Points until the system boots correctly.

That is the fundamental problem that faces me.

Persuing your second recovery suggestion now ( Fedora/Rufus ).

UBCD 5.3.6, Win10 Installer, and EZ Recovery Essentials all failed to find anything to fix.

www.dell.com/.../keyincloud appears to be the logical choice to correct problems, because it understands what the DELL efi configuration should look like.

Unfortunately, I've spent the day trying to get this to work.

I have downloaded the KeyIncloud.zip file 3 times using different methods:

- firefox native download  ( it failed to recognize the .zip extension;  I renamed it.)

- chrome/fdm ( free download manager)  Always reliable for me.

- edge native download.

All of these files have the same SHA256 code.

I tried extracting with:

- WinRar ... I can actually see the files that are there.  It just won't extract them.

- Win10 Explorer ... says the archive is corrupt

- 7Zip ... says the archive is corrupt

I'm now officially "Stuck".   How can I get a valid .zip file?

Other "TryIt"s:

1.  Attempt to install Win10 on a USB SSD drive.  Refused.  Microsoft doesn't support that.

2. Use Acronis TrueImage to restore the internal drive partitions to that USB SSD.

   Dell recognized the drive as an EFI boot device, but the failure is the same as the internal drive.

   Can't say I'm surprised, but I had to try it.

3. If I cannot get a valid KeyInclude.zip file from Dell, I might try a non-destructive

   install on the internal disk to see if that works.

   I believe this will not preserve my non-Microsoft Windows apps.

   I have LOTS ... and they are all hand tuned to behave the way I like them.

This is exhausting ... but the thought of rebuilding this machine from a fresh install

is a  steep climb.  From experience, I know it will take weeks to months to complete.

Update on the KeyIncloud.zip file.

Beyond Compare handles all kinds of archives.

The \1.5.9 directory the front of the archive is ok.

The \EFI directory starts the corruption and CRC problems.

I suspect the archive was built dynamically, and probably

created the .zip file, then tried to append another directory to it.

Probably just creating the archive with a single command specifying

all the directories would repair the corruption.

Just a guess.

I had a pleasant chat with Anurag in Dell Support.  He confirmed there are problems

with the KeyIncloud download;  it is not specific to my Service Tag;  Dell support

is working to restore the service and I should retry the download "in a couple of days".

I promised I would provide my analysis of the issue as I see it, and suggest ways

to implement this in a robust way.   Using BeyondCompare, the broken .zip file looks like this:

The 1.5.9 directory in KeyIncloud.zip file can be accessed by tools that tolerate corrupted .zip files.
BeyondCompare diagnoses this .zip file as having an "end of archive" just before \Boot.

It suggests that this .zip file was created with two commands:

• create 1.5.9 directory into the .zip
• append Boot, EFI, and bootmgr.efi to the zip.

The tool that did this is broken.  7Zip is a free, opensource tool that does not break in this way.  The website says it can be used in commercial environments ( i.e., Dell ).   And if Dell is concerned that an external tool might introduce malware into customer situations, they can build the product at Dell from source.   7zip supports multiple environments and I suspect the relevant ones are Windows and Linux.

Anurag shared with me that there is a huge Dell database that supports all of the Dell products.  Anticipating this means the .zip file is built from multiple directories at Dell, I constructed a test scenario to mimic that.   I'll only share the one that I think is most applicable.

Testing on my own machine, I constructed a 7zip "include file" ( KIfiles.txt ) that looks like this.

C:\Users\Richard\Downloads\KeyInclude\1.5.9\
C:\Users\Richard\Downloads\KeyInclude\Boot\
7Ztest\
7zConsole.txt   

The command I use to create the KeyIncloud.zip file is:

7z a -tzip -bt -mmt -stl KeyInclude.zip @KIfiles.txt

• 7z is a 64-bit command
• a  (add) to the archive name.  No "c" (create) command is necessary
• -tzip   Create ZIPfile format
• -bt      Document the time the command took
• -mmt Run the compressions in multiple threads, concurrently
• -stl  Set the archive timestamp equal to the most recent file timestamp
• KeyInclude.zip   The output archive filename in the current directory
• @KIfiles.txt   -- The list of files and directories to include.
  Names ending in "\" are directories.  It isn't required.  It helps document the environment
  

Questions:

• Won't 7z include the full path name specified in the include file? 
  That directory won't be on customer machines.
  Ans: No.  other archive programs have this issue ( tar, gzip )
  The resulting file structure will look like the directory at the top of this post.
  
  
  
• Does 7Zip compress the files in the .zip file.
  Yes.  The default compression level is "5"
  -mx=0 flag would instruct 7zip not to compress the files.
  There is unmeasurable time savings for setting this.
  -mxx=9  instructs 7zip to use maximum compression.
  Huge elapsed and cpu cost for doing this.
  Tiny differences in .zip file size comparing level 5 and level 9 compression
  
  
  
  
  
  
  
  
  
• If I already have the KeyInclude.zip file built, can I refresh it by loading changed files?
  Yes.  Glad you asked.  Run the same command as above, changing "a" (add) to "u" Update
       7z u -tzip -bt -mmt -stl KeyInclude.zip @KIfiles.txt
  If 7zip does not detect any files need to change, the command runs very fast.
  If new files appear in the directories, they of course will be added in the update.
  
  
  
  
  
  
  
• What .zip filesize differences do you see in this .zip file?
  -mx=5 reduces the .zip file by 3,700,527 over uncompress .zip ( -mx=0 )
  -mx=9 reduces the .zip file by      54,020 over -mx=5 size
  
  
  
  
  
• What about elapsed time for the commands?
  On my machine,
  -mx=5 runs in    27.6 seconds. 
  -mx=9 runs in 320.0 seconds (5m20.4s)
  Running "7z a -mx=9 ..." on the same archive  runs  5m17s ( rebuilds the archive )
  Running "7z u -mx=9 ..." on the same archive runs in 0.98s  ( nothing to update/compress )
  
  
  
  
  
  
  
  
• -mmt   What does that flag do?
  Allows 7z to run compressions on multiple files concurrently in threads.
  7zip easily beats many other archiving compression systems by taking advantage
  of multiple processors.  Especially important if the activity is time constrained
  ( e.g. capturing diagnostic information before rebooting a system )
  
  
  
  

While I'm waiting for the new KeyIncloud.zip file to be built, could someone from Dell Tech Support confirm the instructions provided to build the USB boot.  

www.dell.com/.../SLN298442

These instructions do not look correct for the image contents I'm looking at.

Install the Dell Recovery & Restore software on your working computer

1. Once the file is downloaded to your browser taskbar or Downloads folder, you must extract the .zip file. To do this, navigate to the download location, right-click the file and select Extract All.
2. Click or run the extracted file to launch the installer. The Dell Recovery & Restore installation wizard will appear on the screen.
3. On the Dell Recovery & Restore installation wizard, click Next and then click Install.
4. When the installation wizard is complete, click Finish.

Questions:

• "the file" ... be more specific.  Do you mean KeyIncloud.zip ?
• "R-click/Extract All"
  Win10 File Explorer offers:
  Extract files
  Extract Here
  Extract to \KeyIncloud
• "Click or run the extracted file"
  What is the "extracted file" name?
  This is not a single file .zip file.  There are multiple directories
  The closest thing to a likely executable file is .\1.5.9\setup.exe
  setup.exe looks like the executable that should be run when the USB media is booted.
  What executable should I run to create the boot USB drive from the .zip file?

I reconstructed the KeyIncloud.zip directory structure using a combination of sources captured in the TrueImage backup of the laptop.  The .\1.5.9 directory was ok and contained the bits that were unique to this .zip file .... namely the setup.exe file.

I constructed a "FreeDOS bootable USB drive using Rufus and copied my reconstructed KeyIncloud directory to it.  Boot from the USB, navigate to the 1.5.9 directory and launch setup.exe.

"Executable will not run in DOS".

Exploring the attributes of setup in windows shows it uses a "WinGUI interface".

How is this .zip archive supposed to repair a system that will not boot?

Continuing my investigation I discovered the "Dell Direct USB Key"
www.dell.com/.../SLN179156

It is not clear how this option is useful either.  The video shows the ability to backup files on the non-booting computer, Re-Install a Dell Windows 10 system, and restore files that were collected.

I do not understand how this technique will work either.

Windows applications rely on registry settings.  Just restoring directories and files will not produce a working environment.

Is Dell making progress on repairing the broken boot mechanism?

My preference would be a ISO bootable image that would work correctly to fix the boot error message:  INACCESSIBLE BOOT DEVICE.

Dell diagnostics clearly show the device is operational

Dell Diagnostic Recovery fails to find anything wrong with the boot environment.

Acronis TrueImage is capable of backing up the disk to external USB drive

Clearly there is nothing wrong with the drive except the Win10 UEFI boot environment.

Are we not able to diagnose and repair this environment correctly?

I'm stuck.  I decided to backup a working laptop, then ran \1.5.9\setup.exe