HDShadow

.......................and the proof was in the pudding. I finally received the 6.3v 3300uF caps and have just finished removing the old ones and fitting the new ones. No problems and my soldering was far cleaner than normal too so I was certain there would be no issue in that regard. Turned on the LE Green Xbox and it booted perfectly first time. Left it on for 10 minutes, played a bit of Timesplitters 2 Arcade just as a final test and all is good. So I can only come to the conclusion that it was those three caps blowing which were the entire cause of the problem. Worth noting I think.

As I said earlier, the proof will be in the pudding when I get and fit the replacement caps successfully. But knowing that somebody else has reported the same thing in the past, even if only an unproven claim, is good to hear because I'm going to be very disappointed if it is not just the those blown caps that caused the problem.

Interesting information ^ ^^. Can it be explained why those three caps blowing would cause the problem described ie. it turns on when the mains power is switched on? I've had a good look with a magnifying glass and a x8 lupe at the MB and I can not seeing anything obviously amiss with the traces anywhere, even under the faulty caps. No leakage to cause that sort of problem. I do know that there were reports about the Xbox that poor manufacturing practices at the time allegedly can lead in the long term to trace damage, things like sweat/grease from bare handling of the MB. But there's nothing like that either. In fact the whole of the inside of that Xbox is cleaner than any other I've ever seen of that age. Only a bit of extra dust on the extractor fan blades betrays that it has been used at all.

LE Green UK/EU are all v1.2 - date of my one is 21st February 2003. As I recall it was bought from Amazon in Spring that year only a few months later. The blown 6.3v 3300uF caps are all the black and silver Nichicon type although not marked as such from what I can see. Manufacturing date of those must have been slap bang in the middle of that bad 'cap plague' period SS_Dave's wiki link describes. I've just ordered some low ESR Panasonic branded replacements very similar to the ones I've used before successfully.

Intend to do that too for that very reason even though the clock cap, as said, looks pristine. I just can not understand how all three of those 6.3v 3300uF ones adjacent the CPU heat-sink blew at the same time and no others anywhere else on the MB looking even slightly suspect. If the Xbox had been well used then it might be understandable but, as said, this one has been deliberately cotton-wooled over the years because it is a more valuable LE Green. Bad batch of caps?

Update........................................and you're not going to believe this - I reluctantly opened up the Xbox a few minutes ago. Took everything out above the MB and looked down at the clock capacitor expecting an unholy mess and it is pristine. MB underneath as far as I can see and surrounding area is as clean as a whistle not the slightest hint of bulging or leakage. I was so expecting it to be that I'd focused entirely on the area whilst dismantling it. I'd even taken all the MB screws out in anticipation of having to clean it up underneath, at the very least, I'd not even bothered to look at anything else. When I did it was gobsmackingly obvious what I hope is the entire cause of the problem. The three biggish 6.3v 3300uF capacitors adjacent to the CPU heat-sink have all blown. There's no leakage on the MB below at all but each one is sporting an ugly, very crusty orange/brown cap. Its better than having to faff around identifying and repairing broken traces - but I now have three caps to replace. Hopefully that will be the only fix necessary. Only problem is that having done those cap replacements on two other Xboxes where they were looking bulgy I've only got one spare of that type left. I'll have get some more. So, assuming that replacing them does the job, it is another bit of useful knowledge knowing that if you have the same symptoms described in my first post that the culprit could be those caps, not the much maligned clock cap.

I'm going to open it up later today if I have the time; dreading what I'm going to find. But its odd this is the first time I've had this sort of trouble as I've owned several previously used Xboxes with clear clock cap leak problems I've dealt with in the last few years. None has caused trace damage, at least not anything that has affected the Xbox's operation. A good clean up and cap removal/replacement is all that has been necessary.

I was practically certain the only solution to the problem was to crack it open and not be surprised to see a leaky clock cap has done the damage but I had to ask just in case there was some other fix. Searching around other old post on other forums there is advice on this I missed initially and still some hope that the damage caused may just be bridging two traces and a good clean up with IP alcohol may be all that is necessary. But of course the clock cap will still have to be removed/replaced. No problem with doing that as I bought a small pack of spare 1F 2.5V ones when I needed to replace a couple of others which where looking dodgy in the other Xboxes I have. Just so annoying with this particular LE Green one I'm going to have to do that; I just didn't think about but should have the fact its clock cap was being charged up regularly over the years when I was using the other Xboxes simply because I'd left it plugged in. That's proof of something I've long suspected is the explanation for its lack of longevity for some users but not others, myself included. If it is plugged in 24/7, usually done to maintain the time/date, it ages much faster because it is being used. That is particularly true of the clock cap types whose life expectancy specs are much lower than the other Xbox caps, typically (depending on the manufacturer) 1000hrs at 70°C. Most other caps are rated for 2000hrs at 85°C.

My LE Green Xbox which is very little used and has been kept in practically retail state (never opened) completely out of the blue decided to start itself the moment I turn on the main's power. Its been connected to the same power block as my most used Xboxes for years so when either are on it will have been getting some power to the clock cap but TBH I can't remember when it was last actually used; it has to be at least a month ago. Then this. It won't turn off using the Xbox power button but will turn off using the UnleashX menu option > Shutdown but then immediately powers up again. Its working perfectly otherwise. Clearly something has happened, probably partly due to the hot weather but what? My theory is that I made a big mistake keeping it plugged in so that when the other Xboxes were being used its clock cap was indeed being charged. Despite it not being used regularly that has led to its premature ageing and leaking, doing some sort of damage. I suspect I'll only know if that is correct by cracking open the case which I specifically did not and still do not want to do. So if the cause could be something else which doesn't required me to take its virginity advice would be appreciated.

I've long ago given up even trying to use the specific UX skin making tools. I had UX Architect running on a WinXP laptop and it seemed to me clunky and far from intuitive. The way I've created UX skins virtually from scratch is by using an existing skin as a base template. That's how my mostly original skins started: improving an existing one that had flaws that needed fixing or features I like missing eg. previews. It builds up from there until, eventually you end up with something better and, as said, mostly original. About the only thing I don't do is bother with the UX music player even though that can be skinned too. Its great for playing background music but badly flawed as a music manager and IMHO not worth the effort. UnleashX's own PDF manual is recommended reading as it does cover skin creation, particularly ones just made using the skinning engine ie. no imported images. But even that does not cover all the sources/syntax supported. For instance there is no mention of "zindex" which is the code for layers, practically essential for any sophisticated UX skin construction. Where do find that sort of information? Other skins; where they are more than just a random background picture and a default skin.xml they're your most useful teaching aid for building your own UX skin.

I read about this on another forum where jaekriel777e had also posted about this problem. Xenium is not my thing so I'm interested in the solution too just for informational reasons. Is actually possible to delete the Xenium OS using its own own GUI? Sounds odd; why would anyone want to to do that and if you did how could it be restored?

I repeated my tests on a Xbox v1.1 SID/AID softmod but using the same version UnleashX dash, same TV, same RGB SCART and Component cables. Repeating what I thought I did on the v1.6 with the newly burned DVD-R which the v1.1 Samsung DVD drive likes produced no success at all. Same problem: audio fine but no video display. I was about to give up when I thought I'd try one last go. I cleared the cache again before each try and region swapped the console to PAL with Enigmah using a RGB SCART cable. I then set the UnleashX video to PAL50 only ie. no PAL60, no 480p (which you can set/save with a RGB SCART cable but can't be used of course) and then went into the TV settings and selected NTSC v3.58 rather than Auto. Then I loaded the game disc (no auto-launch) and with the disc still loaded used Enigmah to swap it back to NTSC. To exit Enigmah you need to do an IGR/reboot. The game thus auto-booted and suddenly started displaying correctly. Going back to my TV's colour system settings I swapped that back to Auto from NTSC v3.58, it auto-selected NTSC v3.58 and continued todisplay the video correctly. I've not tried the Component cable yet but I've no reason to think that won't behave just as the v1.6 did and display both in 480i and, when selected, 480p. Hopefully the NTSC v3.58 manual selection isn't an integral part of this 'solution' and the important thing is the region swapping from PAL to NTSC with the disc in the tray. But why it is necessary to go through this rigmarole and then it suddenly starts behaving as normal continuing to do so from then on I can't even begin to guess at.

I extracted and burned the redump files to disc and my results were perplexing:- Xbox v1.6 PAL region swapped to NTSC, Xecuter 2.6CE chip, Evox M8+ 1.6 Customised BIOS, Hitachi DVD drive, UnleashX v572 dash. I won't go through all the video display permutations I tested but I did clear the cache and the content of X, Y and Z drives first. My initial results were very similar to Infinite Clouds. NTSC with Component and RGB SCART whether 480i or 480p no video display at all but perfect audio. So I re-swapped the console back to PAL with Enigmah and tried again. Unlike Infinite Clouds I couldn't get any video display with either cable whether using PAL 50 or PAL60. With Component you can not change the colour system of the TV I'm using, only when using RGB SCART is that possible. So I swapped between NTSC 3.58 and NTSC 4.43 and retried most of the previous tests all over again. No joy. It still would not display the video. I returned the TV colour setting to Auto and, BTW, confirmed that was using NTSC 3.58 when the console is region set to NTSC. If you use NTSC 4.43 or PAL TV settings it is very obvious as the display is in b/w or faded colour with an odd grainy overlay. At this point I wasn't expecting anything to work but something I've tried before with games, Sega ones in particular, to force 480p (before Rocky5 came up with his loader script) , was to swap from RGB SCART to Component whilst the game disc is running. Again no joy but remember this was still in PAL region mode. I changed back to the RGB SCART cable swapped the console to NTSC with Enigmah, accidentally cold booting the game and ...........................................the damned thing suddenly started working! Not only that: hot-swapping the RGB SCART cable for Component caused a reboot. I re-enabled 480p from the UX dash that, rebooted again and 480p was suddenly working too. I tried swapping the cables yet gain and repeated many of the tests that had previously failed and now everything was working. I left it on my standard NTSC M UnleashX video settngs: 480p/faster refresh rate and cleared the cache again rebooted or turned the console off several times and it continued to boot the game perfectly. I haven't tested it on another version Xbox yet (or other TV) and to do that I have to burn another copy on DVD-R as for tests like this I use DVD-RW. My v1.6's Hitachi DVD drive is happy with them but the Samsungs in most of my other Xboxes are not. Can I explain the results so far? No, I have no idea what it was I did that made the game display properly.

Audio but no picture is typical of a region locked game; you get the same thing with PAL Timesplitters 2 if you try to play it on a NTSC set Xbox. But this is weird because the game should play on a NTSC set console but doesn't but does if you force PAL50. That suggests to me a TV issue; can you swap between NTSC 4.43 and NTSC 3.58 support? Do not ask me to explain it because I can't but it maybe that your TV only supports NTSC 4.43 and not 'true' NTSC 3.58 or something like that. I'll try downloading the game and test it on my PAL TV which does support both and another which doesn't and see if I can recreate the problem.

That's a bit of a hard core solution don't you think? There are apparently ways of unlocking a Xbox HDD on PC; I've read advice about that on other forums from KaosEngineer so he's probably the guy to ask about that although it seems to be a quite complex process. The only other way of getting the eeprom from the dead Xbox is using an eeprom reader. That's usually possible if there is not catastrophic damage to the MB. But as SS_Dave points out there are still other, unavoidable AFAIK, criteria invovled. Modded or not doesn't really change anything but if the original Xbox had been softmodded there would be a good chance the eeprom had already been backed up. But even then people do that then don't follow through the whole process which is to back that up to a PC ASAP afterwards too. The eeprom backup is almost useless if it is left on the Xbox HDD. It why advise people softmodding that once their original retail HDD is softmodded they immediately replace it with a larger HDD and put the locked, softmodded retail HDD into safe storage as the ultimate safety net. I even do that with chipped machines ie. softmod the original or spare HDD or build a softmod later by other means and lock it just in case.

The main problem will be if the Xbox was not modded or it was a softmod: reason being that in both cases the HDD is locked to the dead Xbox's MB. If you can get the eeprom from the dead Xbox's MB and you have another, modded, Xbox you can use them together to access the locked HDD.

Soldering in an LPC pin header apparently "......isn't that hard." but I still made a pig ear of my first attempt at that. You not only need good eyesight (and I bet mine is worse than yours - right eye requires +10 dioptres for reading ) but also the right equipment.

Good luck with the RAM upgrade in particular - I wouldn't even dream of attempting that much as I'd like to have a Xbox with the extra memory.

Well......................in this case it has actually proven either to be the new FATXplorer version update or the new driver. I've literately just finished testing the HDD in question in two out of the three 'problem' enclosures and its now working in both with FATXplorer. I'd been in contact with the Eaton Works support team and very quickly they replied that the update would likely fix the matter. Whether it was the FATXplorer update or the new driver wasn't clear but whatever it was worked. Yay! Not important for other Xbox users but the Windows USB/SATA sector reporting mismatch with the same HDD/housing which prevented me from using that HDD to clone another Windows OS HDD via USB still persists. But it makes me wonder if there might be a software or driver fix for that now too. Who do you approach to prompt looking into something that might just be because of niche USB bridge issue? WDC? They'd probably just say to try using a different USB external enclosure...........................which is exactly what I'm doing.

Extraordinary. I have an older version of the same make of USB external enclosure which I bought more recently because it was being sold off cheaply. Just for a lark I thought I'd try the ITB WD in that. Blow me down - it is now being recognised by FATXplorer, the latest update with the new formatting tools. But I didn't use those, no need the content of the already FATX formatted HDD are suddenly now all available. What I do not know is if it was the enclosure swap or the driver update and reboot FATXplorer prompted before I tried to access the contents. The enclosure only claims support for WinXP and Vista yet it works fine with Win7 64bit >.but I've just checked and the other enclosures only claim support for up to Vista too. That would suggest the driver update was the fix but I'll now have to swap the HDD back to one of the other enclosures to test out that theory. Here's the new FATXplorer log for the very same HDD in the alternative enclosure:- FATXplorer Log 2.txt

I should make it clear: the HDD concerned works fine. Using Chimp it cloned the TSOPed Xbox/HDD I was using as a parent hardmod without serious issue except Chimp's refusal to format it to use F only. That was resolved with XBPartioner v1.3. So all is good with the HDD and I could FTP the contents from the PC if I wanted. But I thought I'd like to try using FATXplorer instead. That's when I ran into this weird problem with FATXplorer recognising the HDD as an attached USB mass storage device but not recognising it as FATX formatted. I'm looking for an explanation for and solution to that.

Strangely enough about 8 hours ago I was actually there reading about the new formatting facility and wondering if it would be a solution to this HDD issue too. Windows has no problems even when it is FATX formatted ie. it still sees the HDD in Device Manager and Storage Management as an attached mass storage device with unallocated space. Formatted to NTFS FATXloprer should pick it up and if it has done the formatting to FATX itself it would be a bit odd if it then didn't recognise it as an attached FATX formated device. My money is on it not working and it indeed being a bit odd. But I'm still going to try that because I hope I'm wrong.

That's the theory, yes, and in practice when attached internally, using SATA of course, it reports and behaves as it should do ie. a 512/4096 (512e). However, when using the particular HDD enclosures I have the HDD, as I understand it, appears to report as native 4096. .png I've asked about this on various IT forums and the only explanation offered is that there is, apparently, a problem with some USB enclosures which use a certain JMicron bridge controller chip version. I'm testing that theory by buying another, different make and type of enclosure, but I'll have to wait for that to be delivered.

I knew that but didn't think about trying it in this case. Thanks for the idea. Primarily I was interested as to finding out why Chimp 261812 wouldn't format it to use all free space for F yet, as said, XBPartitioner v1.3 formatted it correcting in just a few clicks. Last night I had another issue with same HDD - I hadn't used FATXplorer for some time so I decided to see how practical it was to install stuff to it on PC, things like apps, homebrew stuff, skin packs etc which I have archived. Had to install ie. update to the latest version of MS.NET Runtime: v5.0 and get the latest FATXplorer Beta version too. All installed, rebooted to be safe and the HDD in an external USB housing that has worked with both IDE and WD SATA 160GB and 320GB respectively. No joy - Windows shows it as an attached mass storage device and FATXplorer detect it too but not as a FATX formatted HDD. FATXplorer Report.txt Tried downloading the new driver, rebooting etc but it still is not being recognised. I opened a ticket on the FATXplorer web site to see if they could offer some insight and/or solution other than the obvious ie. use a different HDD or different USB housing. It is likely something to do with the fact the 1TB WD HDD is "AF" (Advanced Format) and there are reported issues with these newer AF HDD's firmware and some USB enclosures. I was going to use this same HDD to clone an existing internal PC HDD which includes a full Wndows OS but the cloning software refused to proceed because of the mismatched "Sector" sizing. No problem if you connect it by SATA internally but that's a bit of a faff. It was one of the reasons I decided to use it as a Xbox HDD and yet it seems the issue with FATXplorer not recognising the FATX formatting may be related.

Not sure whether this is a Chimp 261812, HDD, BIOS or other matter. I've not used a 1TB HDD with a Xbox before, largest size I've used is 500GB and I've had no problems with Chimp 261812 formatting the extended partition(s). Well today I decided to build a new Xbox HDD using a recently purchased ITB WD AF SATA HDD for use in a chipped Xbox by using a TSOPed Xbox and Chimp 261812 (v1.0). I've done similar things in the past when I couldn't use an installer disc because the Xbox did not have a working DVD drive. All went well and worked perfectly except the formatting of the extended partitions. I elected to have all available space for F but after I'd cloned the existing 80GB IDE 2.5" HDD, BTW just C and E, I was asked again how I wanted to partition the available free space. I checked the Slave ITB HDD's status and the partition table showed the remaining space equally split between F and G about 450GB each. WTF? So I redid it, choosing all F again, but still with the same result. The custom EvoxM8+ BIOS I used for the TSOP is set up for all free space to be used by partition 6 (F) and not to ignore the partition table. So I exited Chimp and used Rocky5's XBPTableWriter to reaffirm all free space goes to F. Went back to Chimp, this time with the 1TB as Master HDD on the TSOPed machine and checked. It was still showing equal split F and G so again I tried reformatting to use all F but still no joy. Long story but I eventually gave up on Chimp and went to XBPartitioner v1.3 and very quickly had the thing formatted to use all the space to F with the correct cluster size (64K) for the 950+GB F partition. So any ideas why Chimp might have been unable to do that?