Please see image attached. I don’t seem to see MAC address there unfortunately.
@Lost_N_BIOS - In regards to SOIC8 test clip, I got burned once. Technically, from an electronics perspective, it’s actually dangerous to do in-circuit programming via clip. Electronics 101. The reason is with standard CMOS electronics, you have Inputs (SCLK, MOSI, MISO etc). As part of design, we make sure that these signals never exceed VCC by a standard diode drop (0.6V). So the other side of the chip (PCH in our case) should have input diode protection tied to VCC.
If you send signals into the flash chip, they travel down to the PCH as well. If the PCH is unpowered, and your signals exceed 0.6V, you can damage the inputs of the PCH.
I tried in circuit flashing once (not a PCH, but a SATA USB board firmware dump/upgrade). Killed the bridge chip inputs. The chip never read the flash firmware anymore and I had to replace the bridge chip. Good thing the chip had built-in firmware if it can’t read the external flash ROM. Either way, the default firmware had bugs so I had to replace the chip.
A modern PCH is a BGA chip, and replacing that would be hard with my current tools. So being a proper EE, I learnt my lesson, and don’t try in circuit flashing nowadays. I’m sure many people do, and get away with it. Just technically, it’s not supposed to be done. You learn that in 3rd year EE at uni. The one time I tried was the one time I killed something.
@alex0 Depending on which OS you are using the MAC address can be in different locations and sometimes in more than one location.
For Windows 8.x / Windows 10 / Windows Server 2012 / 2016 / 2019 you can search the registry for two 32-bit strings that combined will give you your 48-bit MAC address
1. BIMacAddress_h contains the first four alphanumeric characters of the MAC address in the form of 0x00000000h
Mine is 0x0000001Fh, so the first four alphanumeric characters of the MAC address are 00-1F
The brand of my motherboard is EVGA which has a MAC address vendor prefix of “00-1F-BC”
[Edit] For Dell this prefix will be different could be one of these.
2. BIMacAddress_l contains the last 8 alphanumeric characters of the MAC address in the form of 0x00000000h
The first 2 characters belong to the MAC address vendor prefix, so for my motherboard both ethernet controllers have the EVGA MAC address vendor prefix of “00-1F-BC"
Where BC is the first two characters of BIMacAddress_l e.g. BC-xx-xx-xx
I am not going to post the rest of my MAC address here for obvious security reasons but if you have the BIMacAddress_l key present you should be able to see the remaining 6 alphanumeric characters of the MAC address that are unique to that ethernet adapter.
Search the entire registry for both of the keys (BIMacAddress_h, BIMacAddress_l) as they can be stored under “ControlSet001” (from a previous Windows session), “CurrentControlSet” (your current Windows session) and sometimes “NetworkDriverBackup” (from previous driver installations).
For Windows 7 / Server 2008 you can search the registry for “Network Address” and it should be under “CurrentControlSet”.
Your first boot after the MAC adress was erased is your best chance to get it, after that Windows may update the registry (on log-off or shutdown) and overwrite/remove the previously stored entries at “ControlSet001” and “CurrentControlSet”, with the exception of “NetworkDriverBackup” which may be deleted by using 'Disk clean-up”.
@Lost_N_BIOS If you boot that Windows installation on other hardware with any ethernet adapter not disabled in BIOS you can overwrite the registry keys for “CurrentControlSet” and potentially for “ControlSet001”.
Note that disabling the ethernet adapter in BIOS may cause Windows to start it’s diagnostics due to no network being found so you’d want to make sure you don’t start the network troubleshooter in case it resets the network stack (and winsock in the process).
If you must boot that Windows installation on other hardware do it in safe mode without networking enabled.
To start Windows 10 / Server 2016 / 2019 in safe mode use a Windows 10 setup DVD or USB memory stick and the Command Prompt (“Repair your computer” → “Troubleshoot” → “Advanced options” → “Command Prompt”)
Inside the Command Prompt window, type the command;
bcdedit /set {default} safeboot minimal
and
bcdedit /deletevalue {default} safeboot
to revert
In regards to the Windows UUID, I have just googled a lot on this and have come to the same conclusion - the original UUID can’t be retrieved by swapping the drive into another machine as the system drive.
If the manufacturer was the same and the motherboard was the same model there is a small chance that it could be the same if the vendor was lazy and didn’t fill in all the SMBIOS data (or just duplicated it) but Asus usually is not lazy.
It would possibly easier to edit/ read the registry offline without booting the complete system. Install the disk in another system/ via USB adapter as an additional disk, and load the desired registry hive for offline registry editing/ reading as described for example here: http://smallvoid.com/article/winnt-offline-registry-edit.html
- Do a backup of the registry files first, don’t work on the original files
- Don’t forget to unload the loaded hive from your regstry after reading!
@chinobino - I tried looking again. There are no BIMacAddress entries. I googled a bit and I think the BIMacAddress only exist for Atheros Ethernet drivers. The Intel ones do not seem to have them.
@alex0 - So what do you want to do, carry on and fix BIOS without Ethernet MAC ID? If yes, OK, but sorry I’m still waiting for a dump from one of these systems, hopefully one of the users I tagged will reply soon, especially Sleinous, I’m sure he’ll be back in soon.
@alex0 Try looking into HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceContainers The last element of some GUID- entries there is the MAC address for 2 Win10 1909 machines (Realtek) and a server 2016 ess. (Intel).
Might be dynamic entries, didn’t try with loading a remote registry.
(Hive mounted in “local_machine” as “test”, address would normally be: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\DeviceContainers{af2173aa-0888-11ea-b46d-080027e2ca86}
(That’s the fourth machine which has the mac- address as last part of a GUID in this registry tree- but they’re all Win10/Server 2016 ess.)
@lfb6 - I manually loaded the hive (seen in the picture as optiplex_hive). I do know how to manually load a hive from an external USB drive, and copied the files as well for safety. The optiplex drive has not been booted for about a week.
None of my GUIDs are similar to yours, I went through every single one. The Optiplex has an Intel i217LM.
@alex0 Seems not to be a system for these entries…
If your system was pre Win10 and you got bothered by the Win 10 update campaign you might have this key: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows Genuine Advantage] "MAC"="01-23-45-67-89-AB"
Installed somthing from Corel? [HKEY_CURRENT_USER\Software\Corel\PCU] "7"="0123456789AB" "HFNCv2"="0123456789AB"
Or some MS Office? (Office 2016 Ctr) [HKEY_CURRENT_USER\Software\Microsoft\Office\Common\ClientTelemetry] "MotherboardUUID"="{00000000-0000-0000-0000-0123456789AB}"
Sorry for not opening a new thread, but I have a similar problem and maybe It can be helpful if I share here.
I have an optiplex 9020 (dont know if different from 9020m) that died after a bios update, using the Dell update program. No boot. Just black screen
I manage to dump the two flash chips (after the bad update), using an external programmer and also to extract the bios from the .exe file provided by dell. The problem is that I do not know what to flash and where ( PFSextractor created a bunch of small files). Should I have to combine them somehow? Can I flash them straight away, or there are infos that I have to port from the flash dump?
I am attaching everything I have, maybe It can be used to help OP.
Your two dumped files give a complete bios, open both files in HxD, put the 4 MB file at the end of the 8MB file and save with a new name. Open result in UEFItoolNE, should look like this:
See parser list, double click error messages, the relevant go to the second last volume of the bios region, that’s where corruption is. Dell update contains a complete stock bios (empty NVRAM), that could replace the bios region. ME region is update version and new ME region has to be created as in [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization
Several ways to try: - Download bios update A17, replace bios region of your composed 12 MB file with bios region (6MB) from update package A17 (UEFItool 025), divide the file again i a 8MB and 4 MB part, flash both. Will probably work, but you’ll lose possibly your board specific data in NVRAM/ personality in paddnig
- Try to save your NVRAM/ personality: Extract the last 3 volumes of the bios file A17 ‘as is’ and replace them ‘as is’ in your bios. Alternatively (possibly easier) copy stock bios A17 from hex 90.000 to the end in HxD and replace in the 12 MB file from hex 690.000 to the end. Should give again a file exactly 12 MB. Divide in 8MB/ 4MB, flash back. Least ‘invasive’ but higher chance of not working.
I have tried what suggested, but the pc is still dead.
What I have dove
- Merged the two flash dumps (8+4)Mb using HxD - Opened the merged file with UEFItool (I had to use v0.21.5 since the new releases dose not support ‘replace as is’) — First I tried to replace just the last three region of the bios, then divide the image in (8+4)Mb and then flashed using Colibri. — Secondly I tried to replace the whole bios region, then divide the image in (8+4)Mb and then flashed using Colibri.
The result is the same. The pc is still dead but at least now I get the error codes from the power button (2-1 — system board failure — from DELL service manual).
Further investigating I noted that the flash is not detected anymore after the first read request. I suspect that some pin is used for set the write protection. This is also confirmed by the fact that after an erase procedure the flash memory still contain some data that other than ‘FF’. I have desoldered it and read/write procedures works as expected. However, I used this method only on the second attempt (with the whole bios region replaced). Should I try also the first method (desoldered flash + bios with just last 3 regions replaced)
Something that I did not investigated is the ME part of the bios. Should I also have to fix that part? Maybe it does not work because I also have to fix that part?
Last doubt is regarding the UEFItool version that I did use. Is it okay or should I use a more recent version?
------ I refuse to believe that the motherboard has died exactly while updating the BIOS as showed by the blink error code.
Regarding your flashes- sounds a little bit like a bad flash. I use to read back the content of the flash chip with a different program, store it and compare it to the original file. They should (if the system isn’t started in between) be 100% identical.
Bad/ corrupted ME normally doesn’t give these symptoms.
@nrdmtt For the partly replaced bios- there’s a difference I don’t understand (maybe the old UEFItool version?), but then at least the completely replaced bios region should have worked. Anyway- please try the attached bios. I cleaned the ME, too, to be sure. Try the attached 4MB and 8 MB file.
The FPT partition table header checksum seems to be an error in UEFItoolNE, the other errors are present in stock bios, too. That type of errors is not too rare- if an error is present in stock bios, too, I don’t care too much.
As written before: Read the chips after flash, store the result, and compare original file and read file, they should be 100% identical (HxD, analysis, data comparison- or command window => fc /b file1 file2)
