PDA

View Full Version : XP failed boot - interesting cause (Android device)


The late XV105
24th Oct 2010, 13:16
ASUS P5N32-SLI home PC with E6600 dual core 2.4Ghz CPU, 3.0GB physical memory, Windows Updated XP SP3 Media Center Edition 2005, four internal HDDs - each of these partitioned - plus two eSATA HDDs, two USB 2.0 HDDs, and a gigabit networked RAID1 NAS. Regularly housekeeping has maintained stonking performance of this set-up since it was new in December 2006 and up to date security and careful usage has kept it virus free.

I was therefore puzzled last week when it failed to boot beyond POST. It gave the beep, but then nothing more. Everything I did to do with power failed to help. Thinking that after four years it was likely to be the CR2032 BIOS battery at fault, I removed the mains power, waited a few minutes, and with myself earth bonded, removed and replaced it.

Eureka.
Boot.

The next day though, no boot.
Humph.

Removed the BIOS battery and reinserted the same one (new, remember, and voltage was fine). Boot again. Phew. This time though I decided to change the ASUS splash screen for the detailed boot screen by pressing DEL to enter the BIOS set-up. This was me thinking I'd like to see what was going on if it failed to boot again.

Sure enough, the next day, it failed again. This time though I could see that after the POST "beep" the PC ran a successful memory check but failed to validate any of the devices; none were listed.

At this point my HTC Desire mobile phone rang, so I unplugged it from the USB lead I use for charging, and took the call. After the call I did not re-plug it.

The PC booted the next time I tried, without needing to take out and re-insert the BIOS battery.

It then dawned on me that since the phone was new I have been charging it using a USB mini-B cable with a micro-B (charging only, no data) converter on the end. The evening before the first failed boot however I changed this to a full micro-B cable (charging and data). The cause of the failed boots was therefore the PC recognizing the Desire (Android 2.2 for the record) as a device, remembering this in the BIOS, but then failing to load it at next boot. Removing the BIOS battery cause the motherboard to revert to defaults and forget the Desire.

The solution to my problem is therefore simply to make sure that the Desire is connected a few seconds after POST if it was connected during previous PC usage.

Keef
24th Oct 2010, 17:29
Nice bit of diagnosis!

I don't switch off my PC from one month to the next (except when there's a power cut, like the three last night) so I don't have this problem :)

Simonta
24th Oct 2010, 19:54
Thanks for the heads up XV105. As an Android developer, I am interested in your story - and well done for finding the cause - the kind of problem that can fry the brain for many an hour!

I fully understand if you are too busy to do this, but I would be really interested and most grateful to know if you have the same problem if Android is set to default to "Charge only" on connection. I can't reproduce this myself as none of my BIOSes are smart enough to remember USB devices.

All grist for the knowledge base mill.

Thanks again

Regards

Simon

The late XV105
24th Oct 2010, 20:49
Thanks for the kind compliments, Both. Despite a logical approach though there were a few hours and some cussing involved in the final step before the penny dropped! :)

To answer your question, Simon, the phone was in "charge only" mode since it was connected to the powered up PC with the keypad locked, and it remain locked thus until some hours later the PC was booted. I will however try unlocking the keypad and then restarting the PC before the keypad has locked again (I'll temporarily set a five minutes keypad time out to play very safe) to see if "inverse logic" happens!

For completeness of interim info the two top panel USB sockets on the PC stay live even when the PC is shut down. Only if I flip the power switch on the PSU itself do they lose power. It is for this reason I have got in to the habit of using them for charging.

Stay tuned for the feedback promised above,
XV

The late XV105
24th Oct 2010, 21:11
Hi Simon,

The feedback that I promised: It makes no difference whether the Desire is locked or unlocked at the time of PC shutdown or boot and it also makes no difference whether it is in "charge only" or "mounted drive" mode when shutdown is inititated; the PC's subsequent boot "hangs" immediately after performing the memory check.

I additionally now know however that if the USB lead is pulled out of the Desire whilst the PC is hung, it immediately (absolutely no discernable pause) resumes booting all the way to success; handy to know that I don't need to go through the BIOS battery palava given that I probably will sometimes boot the PC with the Desire attached.

XV

Feline
24th Oct 2010, 22:10
XV

I recently had a somewhat similar situation - machine just booted to a blank screen with a flashing cursor. Cutting out a long and tedious story - I had at sometime in the past changed the Boot Sequence to boot from a USB device, and then from the HD. This went undetected for some time as I (nearly) always remove USB devices after shutting down the system. But on this particular occasion I had left a USB memory stick plugged in - and it took me quite a while to realise what was happening. So - have you changed the boot sequence at some stage and not changed it back? Just a thought - it might simply be that and not the Android?

The late XV105
25th Oct 2010, 09:03
Hi Feline,

No, it's not the boot sequence (1st - CD ROM, 2nd - HDD, 3rd - Disabled, 4th - Disabled) but you may be on to something in terms of the Desire appearing as an HDD even though it ought not; With the BIOS editing window open, I plugged the Desire in to the usual USB port and then tried to refresh the list of HDDs to see if it appeared. I couldn't, because the PC keyboard stopped responding. The Desire keyboard was locked when I plugged it in, but unlocking it confirmed "charge only". I then unplugged the Desire, and the PC keyboard immediately became active again, even performing the buffered commands.

XV