[Need Help] Flashed Wrong BIOS to my Alienware Area-51 R2

Thank you! I appreciate it.

That’s crazy and makes sense because I have never seen Driver Booster ever come back on their scan report and suggest updating firmware, just the drivers that were on my machine. It checked those drivers and most of the time there were not a lot of updates if any at all. So their application may have communicated to MS and pulled that up somehow. That’s interesting.

Thank you for doing this! I really appreciate the time you have taken to help me out and even restore my service tag, you are seriously awesome! I have learned a lot. I will do this later today and attach the dumped BIN file.

I completely understand the risks of bricking my BIOS (actually bricking it this time). I hope not but I know that is something I can possibly (hopefully) restore. Those dam SPI1 pins get in the way and have to be bent, unfortunately.

I will indeed wait before I do the clean installation.

Thanks again!

You’re welcome, I’m learning, too.

By the way: If you plan to use the programmer more often on this machine get you an adapter cable. This SPI header looks like a connector for external programming, and looking into https://www.tachytelic.net/wp-content/up…-R2-MS-7862.pdf should confirm that those pins go directly to the SPI… (page 22) There seems to be a ME-recovery jumper, too, which probably would unlock the flash descriptor? (Yours is anyway unlocked since the stock bios did have the locks disabled).

I did the DOS flash and the dump via my USB boot drive; it was quite easy and quick. No issues.

My Findings:
- The Service Tag is now in my BIOS!
- I am seeing "Hard Disk:UEFI: Samsung SSD Plus 1TB, Partition 1" again as the 1st boot instead of Windows Boot Manager.
- I never saw a location to find a serial number in the BIOS.
- Dell Support site now can use Dell SupportAssist to run diagnostics
- Dell SupportAssist application on my PC has the correct Service Tag but no Express Service Code or Processor and the Memory just says GB (none of these I am worried about). The Dell Support site can identify it all. Maybe this will fill in when I restart next (it did not).
- I was able to successfully log in to the Dell Support Assist application. It would tell me there was an error after the hiccup.

It booted up just like it did before the system firmware hiccup. The code will tell, but I am not quite sure what you could improve on with the BIOS?

I attached the dumped file. Thank you again for the help! It’s quite amazing that you can interpret binary code.

I am bookmarking that link you sent just in case. That sounds like a better plan but I do not plan on programming my BIOS much. Thanks for the link and the info!

[Mod Edit] BIOS removed at member’s request.

I can’t- I use programs which can…

Thanks a lot, it seems to have worked so far, even with the result a little unexpected, seems that the newer bios handles this a little differently:



In your backup of the bricked firmware both NVRAM volumes were equivalent, now the second volume is rebuild, but has just links to items of the first volume (StdDefaults for example). But it seems to work…


One last question: Did you experience problems with your Windows activation? One of the missing Dell NVRAM entries and the missing license code in padding could’ve been related to that, if you Windows came preinstalled with an OEM license.


Regarding the firmware in device manager: These entries are automatically there from Haswell, I think- might be a certain UEFI bios version, bot I have old Sandybridge and Ivybridge Laptop which lack these entries and two Haswell machines which both have it. They should be related to c_firmware.inf, a standard Windows ‘dummy’.

[Version]
Signature = "$WINDOWS NT$"
Class = Firmware
ClassGuid = {f2e7dd72-6468-4e36-b6f1-6488f42c1b52}
Provider = %MSFT%
DriverVer = 06/21/2006,10.0.19041.1

[ClassInstall32]
AddReg = ClassInstall_AddReg
AddReg = FirmwareInstall_AddReg

[ClassInstall_AddReg]
HKR,"%ClassDesc%"
HKR,NoInstallClass,1
HKR,IconPath,%REG_MULTI_SZ%,"%%SystemRoot%%\System32\setupapi.dll,-159"
HKR,"Default Service",""
HKR,BootCritical,1

[FirmwareInstall_AddReg]
HKR,FirmwareMaxRetryCount,%REG_DWORD%,2

[ControlFlags]
ExcludeFromSelect =

[Manufacturer]
%MSFT% = Microsoft,NTamd64

[Microsoft.NTamd64]
%FirmwareResourceDesc% = FirmwareResource,GenFirmwareResource
%SystemFirmwareDesc% = FirmwareResource,UEFI\CC_00010001,GenSystemFirmware
%DeviceFirmwareDesc% = FirmwareResource,UEFI\CC_00010002,GenDeviceFirmware
%FirmwareDriverDesc% = FirmwareResource,UEFI\CC_00010003

[FirmwareResource.NT]
; Nothing

[FirmwareResource.NT.Hw]
AddReg = FirmwareResource_AddReg

[FirmwareResource_AddReg]
HKR,FirmwareVersion,%REG_DWORD%,0

[Strings]
; localizable strings
MSFT = "Microsoft"
ClassDesc = "Firmware"
FirmwareResourceDesc = "Firmware Resource"
SystemFirmwareDesc = "System Firmware"
DeviceFirmwareDesc = "Device Firmware"
FirmwareDriverDesc = "Firmware Driver"

; non-localizable strings
REG_MULTI_SZ = 0x00010000
REG_DWORD = 0x00010001

Please uninstall the firmware by right clicking on it in device manager, ‘uninstall device’. If there’s a checkbox for ‘Delete the driver software for this devce’ check it before clicking OK

If you could choose ‘Delete the driver software for this devce’ and you did get a positive feedback for this process:
Check if the Vostro firmware file you found in #17 is no longer there
If it disappeared => reboot, check device manager, open firmware, select tab properties=> property: Inf name, value should be c_frmware.inf


If the Vostro firmware file still was there OR If you couldn’t choose '‘Delete the driver software for this devce’ open a Command prompt as administrator.

Run notepad c:\windows\inf\oem32.inf and re-check that oem32.inf is the inf file related to "Dell, Inc." "System Firmware 1.0.8"
If that’s the case
Run pnputil /delete-driver oem32.inf /uninstall

If you get an error message that the device is in use
Run pnputil /delete-driver oem32.inf /uninstall /force

Check if the Vostro firmware file you found in #17 is no longer there
If it disappeared => reboot, check device manager, open firmware, select tab properties=> property: Inf name, value should be c_frmware.inf


If the Vostro firmware file still was there delete the firmware- folder in c:\windows\ .

Reboot, check device manager for properties of firmware- device…

Please report what you had to do to get rid of the oem
.inf and te firmware file!

Oh okay, it seems so hard to find things on binary code for BIOS’s. I could be using the wrong search terms.



I got Windows so long ago that I don’t remember much about it but I ran the command Slmgr –dli and I am running OEM. I have never had issues with activation, it’s attached to my Microsoft account so I just sign in and I am done. I never had to activate Windows during this whole process either.

Well, I am happy it worked out. I feel much better, thank you! You are seriously a champion.

I have two questions:

1. Since you and MeatWar are fairly confident that I did not brick my BIOS or the firmware update never reached my chip, should I flash my "bricked" backup BIOS via DOS from a USB? If that BIOS isn’t corrupt, why shouldn’t I restore it (too much a risk maybe)?
2. If I used the BIOS exe file Dell provides for me via DOS on a USB, would that possibly correct, erase what you did, or harm anything? What would the result be, I am curious?

I went to Device Manager, clicked uninstall, checked the box to delete it, and it was gone from Device Manager and was immediately replaced with c_firmware.inf manufactured by Microsoft and provided by Dell, and then I restarted. The oem32.inf/pnf files are gone. The Firmware folder is empty (can I get rid of it). I searched the registry and could not find FirmwareFilename but I did find this:

New UEFI.jpg


Both in the same location as before - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\UEFI\RES_{7039436b-6acf-433b-86a1-368ec2ef7e1f}\0 and here - HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\UEFI\RES_{7039436b-6acf-433b-86a1-368ec2ef7e1f}\0

EDIT: Should I do a clean Windows installation?

OK, good! Then everything is as good as it could be. Please keep your firmware backups- at least the one before the brick, the latest bios region (I sent to you) and the dump you made after you flashed it.

Reflashing your old bios was an option, but I rated it more risky than the chosen option. Differences

There’s one relevant difference to your old bios, it’s the flash descriptor, which is unlocked now:

fd.jpg



Gives a little security since it protects FD and ME from getting overwritten, but many people unlock it anyway since it’s easier to flash for example a corrupt ME with a cleaned one. Command would be fpt(w(64)) -fd -f fdorg.rgn (fdorg.rgn from attached file)

When you reflashed the firmware with stock a14 ROM you replaced the ME region with a clean configured one from the update. It’s not clear if a Dell update would do a same version update or just leave it as it is.

When you had this ‘whatever’ happening we can conclude that the static parts of the firmware were 100% identical to stock A14, but that’s not automatically true for your NVRAM. As written before, it’s quite easy to write there from within the OS, and these values won’t get overwritten by a bios update. So I can be sure that the firmware itself was unchanged, but I can’t be a 100% sure that there weren’t some settings changed in NVRAM that messed it up for you and I haven’t got a method to check if all these entries are valid and good… NVRAM store gets repopulated automatically except for machine specifi entries, like service tag and serial number, OEM license.

So I myself would use the firmware as it is right now.

But it’s fully possible to flash the complete backup or just it’s bios region for checking (I’d leave the ME untouched since newly overwritten with a clean stock ME). But in case you flash the bios region there’s a chance that NVRAM settings are corrupt and require you to use the programmer again…


The Registry entries are just fine, they’re identical to mine except for the GUID.

12.jpg




If there’s a real need for reinstalling Windows? If so it won’t be connected to this event.

fdorg.zip (353 Bytes)

You are a lifesaver. Saved me from having to reinstall Windows and got my BIOS back to what I remember. Thank you, I seriously appreciate your help and expertise; you went above and beyond. I just wish I found this forum earlier. It was fun (really fun) and a great learning experience.

I am eventually going to upgrade my motherboard, RAM, CPU, and GPU in the next year. Once I replace my motherboard in the next year or so, I am going to just try to flash the old BIOS back and see what happens.

I am just going to leave everything as is. No need to do anything rash. I am going to look for some programs like you have and look at the BIOS images, I find that stuff really interesting.

So if I ever do a clean Windows installation in the future I might have issues, won’t have any issues, or will that OEM get reinstated to the NVRAM?

I am now going to dump my brother’s Alienware BIOS just in case. I think it’s important to back everything up.

Thanks again for the help.

EDIT: My Dell SupportAssist application now has all of my information like my Express Service Code along with everything else.

Thank you! And yes, it’s (normally) the better way to understand what happened and to fix the consequences.

As written there’s a Windows license in the bios, code is for “Win 10 RTM Core OEM:DM” (Core meaning Home) and it’s none of the standard dummy codes. But when you have your license linked to your Microsoft account it will anyway not be a problem to activate a reinstalled Windows.

It might be interesting of the licensing code in the bios is restored correctly. Please open a command prompt as administrator and run wmic path softwarelicensingservice get OA3xOriginalProductKey That should normally give you a OEM key, probably the key you saw parts of in #12. Or you might use showkeyplus, output might be somthing like this:

produkey.jpg



(The ‘Installed key’ is a dummy key that won’t activate Windows, the OEM keyis from a 2013 laptop for Windows 8 home, so I don’t care to show) If showkeyplus displays “OEM key not present in firmware” or wmic gives you an empty answer then I did something wrong… If you get a key compare it to the one in padding after NVRAM (0x80014 to 0x80030 in bios region)


You might observe your Windows behaviour a little- if everyting is working as expected, no bluescreens, no crashes, OK performance- just leave it the way it is. It might anyway be a good idea to do a fresh install when you change your hardware! (But then you existing license might no longer work since tied to your old hardware)

Yes, it’s a digital license so I never got my key. I checked the Padding below NVRAM and compared that key entry with the key that the cmd prompt populated and they are both the same, and that photo in #12 is definitely part of it. Does the cmd prompt populate the key from the NVRAM? How would I know that is the correct key? Would my Microsoft make me verify it’s me or would I have issues with other things in Windows?

I used ShowKeyPlus and it’s the same key as everywhere else. I read it finds the code via C:/Windows/Sytem32/Config/Software so I am assuming it was imported correctly by you. Thanks for that!

So far, my Windows behavior has not gotten the blue screen again but if it does happen again I am just going to do a clean install. I think it would work on new hardware just because I have Windows on two other PCs. It might make me remove Windows from another PC before I can continue with the new installation on the new hardware.

I cannot wait to get the new hardware but RTX 3060 graphics cards are either sold out or $800-$2,000 instead of $330. It’s insane. We’ll see what happens in a year or so.

The key has to be presented in the MSDM ACPI table, I think there are several implementations how the bios itself can do this. (https://dellwindowsreinstallationguide.c…reinstallation/)

Since both wim and ShowKeyPlus (in the lower part) access this ACPI table, it’s the same information a fresh Windows install would get presented, so that seems to be OK, too. The key in the registry was there since installation and the ‘brick’ did not make Windows deactivate itself- maybe since you had you license linked to your account.

OK, so far. All the best for 2022 and good luck with your new PC. Make a backup of the original firmware right when you get it


HAHA I will! You won’t have to worry about that lol.


Makes complete sense, it is probably because I had it linked to my account.

I feel much better having my PC back to what it was. Scary times.

Thank you again for helping me with this. I very much appreciate it.

I wish you the best in 2022. You have a good one.

Not trying to reopen this but I had one more question.

I backed up my brother’s BIOS using the ME firmware tools so it was just the BIOS region. If something happened to his BIOS and it bricked the motherboard, how would you restore the BIOS with half the file size? If using a programmer to flash that BIOS region back to his BIOS, would that automatically just write to those regions or would he need the full 16,000KB file?

Did you try to backup the other regions with fpt? At least descriptor should be readable. fpt -i will give you the different regions. Sometimes stock bios is a complete image as it was for your Dell, the ME region can be taken therefrom… What make of pc is this?

It’s an Alienware Aurora R6. I am not sure how to back up every region with fpt to one file. I did not go into DOS, though. I used the fptw -bios -d biosbackup.bin only so far. I see the commands for all of the other regions:

-DESC Load/verify/dump Descriptor region.
-BIOS Load/verify/dump BIOS region.
-ME Load/verify/dump ME region.
-GBE Load/verify/dump GbE region.
-PDR Load/verify/dump PDR region.

Is there a command that just loads every region to one file?

EDIT: I think I could just do fptw -d backupbios.bin. I will try that tomorrow.

You did that already here: [Need Help] Flashed Wrong BIOS to my Alienware Area-51 R2

Alienware Aurora R6 bios is just bios region with an unconfigured ME update file attached in last efi volume. Use AMI_UCP_Extract for extraction.

Yep, I did; completely forgot. I will download that from GitHub and extract it. Thanks for the help!