Originally posted by: RideFree
You guys are going to look funny with egg on the egos...
When XP writes to the Master Boot Record (MBR) of a PC's hard drive it is the very first physical sector on the disk (0,0,1 in head, cylinder, sector terms). There are some special things about the MBR. It contains (at a minimum) some executable code to start the bootstrap of the operating system. This can affect partition tables, logical and virtual drives as well as the status of the whole subsystem, itself.
The bootstrap of the OS that is being considered in this equation is none other than DOS, itself.
It may be possible to run "fdisk /status" to get an idea of what may have gone wrong.
I would advise against running the undocumented "fdisk /mbr" without a master boot record backup.
I do not consider it to be a possibility that some card is interfering with either IRQ 14 or 15.
Other possibilities for the problem have never been excluded by me and I remain open to the real solution, one of which I have put forth here.
Better to be thought a fool than to open your mouth and remove all doubt.
First, let's get that little IRQ thing out of the way. This is an ACPI system. It does not use old ISA, EISA, VESA style interrupts where an interrupt represented a physical line going to the processor. If we still did things that way we would be limited to 16 devices in the system. No, we're using interrupts now that communicate via packets. It is perfectly normal for two devices to share the same interrupt.
Second, let's get a little fdisk issue cleared up. WTF is Fdisk /status? That's a DOS switch and doesn't exist in XP (we use the LDM in 2005 m'kay?). Further more, Fdisk /MBR is a perfectly safe command to run unless one condition is present: The end of sector marker for sector zero (55 AAh) is missing. Fdisk /MBR simply rewrites the MBR boot code and then zeros everything else in the sector until the start of the partition table. It calulates where the partition table starts by counting backwards from the 55AA. No marker? Zero's your partition table out. Why on earth would you think Fdisk /MBR is undocumented? It's well documented. SELF documented even! Run Fdisk /? geez.
Finally, let's get this whole MBR thing cleared up. The boot code in the MBR is OS independent. It's the same boot code whether you're running DOS, or Server 2003 Enterprise. It is not an operating system and performs no operating system functions. It is enough code to read the partition table, find the active partition (80h marker) then locate and run the boot sector at the beginning of that partition. The MBR boot code contains no dynamic information whatsoever and has absolutely nothing to do with this problem. The MBR code runs in realmode. Windows runs in protected paging mode. (Shell on top of DOS?? - what a riot!!). The moment the MBR passes control over to the boot sector you have become OS specific. The boot sector dropped in place by formatting with an NT based OS like Windows XP (NT 5.1) looks specifically for NTLDR. The boot sector dropped in place by DOS looks for IO.SYS or MSDOS.SYS (for the life of me I can't stretch back two decades to remember which).
Now explain to me how Windows' ACPI.sys which loads way after ntoskrnl.exe, which loads after ntldr, which loads after the boot sector, which loads after the MBR, which loads after BIOS can make any changes to what BIOS sees when you go into your BIOS setup screen and aren't even accessing the disk?
To save yourself future egg, please know that I edit disks by hand with a hex editor. I can completely rebuild a lost sector zero and get an OS booting again. Don't try pulling any wool over my eyes. I'll get impatient and flame you.
Let's leave the remainder of this thread clear of any bulls*** so we can help KuJax with his problem. Please ban yourself. Twice.
Facebook
Twitter