Uses the post code 00 for Asus X99-Pro.
Uses the post code 00 for Asus X99-Pro.
I possess an older Asus X99-Pro board that has performed well over the years. On the morning of June 23rd, I noticed the machine rebooted unexpectedly and remained stuck with post code 00. Despite multiple restarts, the issue persisted. None of the fans were operating. At that time, an i7-5820K was installed on the board. I upgraded my BIOS from version 0401 to 3801 on June 16th for a RAM upgrade. The machine functioned normally until the incident on June 23rd. Asus indicated a dead CPU, but I remain skeptical due to past experiences with similar problems on newer systems. Recently, I replaced the CPU with a used Xeon E5-2683 v4 from an eBay seller. This new CPU appears on the QVL list for my board, yet my setup still shows post code 00. I have tested the board without any components and consistently received post code 00. I also attempted single CPU installations, a single stick of RAM, and even used the BIOS flashback tool on USB, but none resolved the problem. I’m not confident in ASUS support given my history with other boards on a newer machine. I’m open to investing in testing equipment like a PSU tester if necessary. My PSU is a Corsair RM750, and I’ve noticed the fans remain silent even when using a jumper. I managed to power a CD drive with the modified PSU, but further troubleshooting is needed. I’m hoping for guidance without spending $200 on a new board, but I’m prepared to invest in diagnostics.
Thank you for your input @TimedPing. I recently purchased a CH341A Flasher from Amazon and also bought some backup EEPROM chips (W25Q128FVIQ) on eBay. I shared a photo of what appears to be the EEPROM on my board. It has a socket and the part number suggests it’s a 16MB storage unit. I intend to attempt to transfer my current EEPROM data to see if I can retrieve any configuration settings. I’ve already figured out how to pull the raw image from CAP files on the Asus site, though they lack the necessary config info for my board. I’m also aware it’s feasible to reconstruct the data from the dump and merge it onto the extracted image using some system-level editing techniques. I can confirm parts of my setup by checking the labels on my board. I prefer not to flash my existing chip because ASUS embeds configuration data directly into these chips, which is why I opted for new ones. (Having done cyber forensics makes this feel unethical.) I found several guides on performing the flashing process below: a video on using a CH314A, a text summary of a guide from miyconst, a discussion about ASUS BIOS recovery with EZP2010, a tutorial on flashing via USB Asp, a tool for updating BIOS settings, a GitHub repo for config updates, and a forum thread on flashing and recovering BIOS on similar boards. I plan to verify my changes using the sticker information on my board. My goal is to preserve my original configuration without risking damage. I’m following the instructions carefully so anyone reading this can replicate the process later. Regarding the W25Q128FVIQ specs, it runs at 3.3V while the CH341A seems to need 5V. Do you think a voltage adjustment is necessary for the CH341A? I found a helpful video on this topic here: https://www.youtube.com/watch?v=-ln3VIZKKaE. I’ve updated my notes with this link and others for reference.
I investigated the voltage level problem on the CH341A and found the CH341A V1.7 resolved it. I canceled my initial order for a CH341A and purchased the V1.7 instead. I also realized that setting 0.2V above VCC (3.3V on CH341A) isn't supported on the W25Q128FVIQ, which required attention to the voltage issue. I'll share an update once I have the equipment and attempt to clear and fix my BIOS.
I just gathered everything needed to manually update my BIOS. It didn’t solve the problem, but I’m sharing my steps in case you have any tips. Here’s what I did:
I used a CH341A V1.7 at 3.3V, set via NeoProgrammer to the W25Q128FV profile (my chip is a W25Q128FVIQ). First, I captured an image of my current BIOS chip using the tool. The UUID wasn’t listed in FD44Editor, but I found it by analyzing my MAC address with a hex editor.
Next, I downloaded the latest BIOS (v3801) from ASUS and extracted it from a CAP file using UEFI Tool.
Then, I added my board details—SN, MAC address (from stickers and old dump), and UUID (from hex edit)—to the image in FD44Editor.
After that, I flashed the customized BIOS v3801 onto my chip using the erase, blank check, write, and verify steps.
The machine still shows postcode 00 with the Xeon E5-2683 v4 installed from eBay.
I tested BIOS versions 0401, 1004, and 3801 using ASUS EZ Flash, but only the latest (v3801) worked.
I also tried cleaning CMOS, stripping the board, and using a USB BIOS Flashback device.
If I get a different postcode (like missing RAM), that would be a sign to move forward.
I’ve checked the power supply with a jumper and confirmed it works for DVD drives.
For USB BIOS Flashback, I had a drive plugged in and it powered on.
I attempted to flash other BIOS versions but only v3801 succeeded.
My plan is to flash the pre-installed BIOS before removing the board, unless I have to keep it in a case.
I’m also considering converting this machine into a Linux server if I can’t fix it, but I’m not sure how Asus warranty covers this.
My inventory includes: ASUS X99-Pro (likely dead), LGA2011-V3 Core i7-5820K, Xeon E5-2683 v4 (LGA2011-V3), 2x DDR4 Corsair CMK16GX4M4A2666C16 16GB, C16 Kits, Corsair Vengeance fans, a case, PSU, and a DVD burner.
I’m open to advice on next steps unless you’re just helping for fun.
Hello! I'm experiencing the same problem with my X99-A/USB 3.1 setup. It seems that after removing the HDD, graphics card, and performing a clean CMOS reset, the system eventually passes the 00 code and boots normally. This happens repeatedly after several power cycles with intervals of a few minutes. I leave it overnight and the same thing occurs—code 00 appears, requiring another CMOS reset and disconnection. Some users suggest it might be related to temperature, though I haven't tried heating the BIOS area or connected ports. Also, I'm unsure if multiple CMOS resets helped if the SATA or graphics card were still connected.
In summary, the timing of the problem wasn't clear. It might have been functioning well after several restarts, but once it was left unattended for a day, it wouldn't start up. I removed components gradually and didn’t think it was related to compatibility or the processor itself—the diagnostic lights were operational, and I could observe various checks. Still, no POST was achieved and the code remained 00. I also tried swapping the BIOS chip, but it didn’t alter the outcome. Then I found a forum discussion that offered guidance on diagnosing motherboards and checking voltages. It mentioned that the ME voltage feeding the hub needed to stay within a certain range, and I managed to replicate the issue by observing the voltage dropped to about 0.95V instead of the expected 1.05V in a faulty setup. When the system booted normally after clearing CMOS, the voltage returned to normal. Whenever it failed, the drop was noticeable. I attempted heating and using an SMD heat gun, but no significant improvement occurred. Eventually, replacing the RT8065 DC-DC converter seemed like a practical step. It wasn’t the simplest fix, as it required handling a tricky ground plane and using an SMD heat gun, but it was necessary. Some users suggested the problem could lie in the hub or possibly within the DC-DC converter itself, though I found the feedback resistors and voltages to be within acceptable limits. Measuring the feedback helped confirm normal operation when correct, but in a faulty state it could be erratic. Overall, I believe checking the ME voltage and ensuring it stays within tolerance is key. If abnormal readings appear (some even reached 1.6V), replacing the RT8065 is a reasonable first move—it’s affordable and straightforward. This approach, though technical, offers a solid starting point for troubleshooting similar cases.