XBR is a wonderful hack but I believe it was premature in its release as its opperation to do what it was intended to do is unstable as well as non modified every day features. Here is my research so far. After MANY test's I can conclude that XBR is reading xex's improperly. To test this I have done the following. I chose Halo 3 as my test subject since it has multiple releases using the same engine and file structure. XBR -> xexloader (LIVE HDD) -> Internal HDD -> Halo 3 (MEDIA FLAG REMOVED ONLY) = Instant freeze in maps XBR -> xexloader (LIVE MEMORY CARD} -> External HDD -> Halo 3 (MEDIA FLAG REMOVED ONLY = Instant freeze in maps XBR -> xexloader (LIVE HDD) -> Internal HDD -> Halo 3 ODST (MEDIA FLAG REMOVED ONLY) = conditionary freeze via shield damage Last Resort XBR -> xexloader (LIVE MEMORY CARD} -> External HDD -> Halo 3 ODST (MEDIA FLAG REMOVED ONLY = conditionary freeze via shield damage Last Resort. Now to make sure it was not a corrupt rip causing the errors I swapped the maps folder in Halo 3. In doing so I swapped the "=" effects. This then confirmed for me that it is the xex's / dll's being read improperly. To make sure I did all the above tests with a LIVE file as a bootloader (not exceeding 4 gigs) same results as above with xexloader applied. To go on to test other XBR functionality. Booting the xbox 360 with a Xbox LIVE profile set to auto sign in with network connection results in booting to a black screen. With auto sign in off when connecting to LIVE via the dashboard it causes a freeze. When signing ingame and returning to dashboard it causes a blackscreen freeze. When recovering a profile no freezes occur and upon returning to dash it is stable untill signing out and then back in. This then indicates that there is a problem in profile.xex or dash.xex. Also memory usage in loading games / apps homebrew or not can sometimes cause the xbox 360 to "die" and to kick it back up you must double tap the guide button to wake it up. i.e. XBR -> xexloader -> blackscreen -> double tap guide -> load Also on a final note within XBR after running a HDD LIVE file and then pressing eject manually or in guide when within a HDD game causes the xbox to stop recognising the storage media. This may only be caused because I have no disc tray but this is not the behavior with a retail kernel so thus it is a bug. Even though it does not detect any storage media when removing the memory card I get "Xbox must be rebooted due to removal of important storage media" Or a similar message. Media will not show back up unless rebooted and for the error message you can only chose okay. On a final note Halo 3 ODST XEX/DLL had recoverable eject button freezes where as HALO 3 XEX/DLL did not. These are the things that need to be addressed in the newest release of XBR. Unstable App boot time Unstable Live Dash Unstable XEX/DLL read
Which versions of the Halo 3 XEXs were you using? Direct from original retail disc? Merged with a patch? Did you clear your HD cache before using it to ensure that the system wasn't trying to apply a patch to a modified XEX? Also, have you thought about giving it a go with a few Unreal Engine games? Bungie does put together some pretty decent anti-hack stuff so it's also possible that you could be running into something there. This isn't to say that XBR is perfect. Just trying to toss out some possibilities you may not yet have thought of. Also, did you just test in XBR or did you manage to get that Cygnos installed and test in a freeBOOT environment as well? -hl718
When you connect to live the console downloads a fresh signin.xex and runs it. Maybe that's why you're having the freezes. I don't get why the hell people would want to put a kernel hacked console on XBOX live though.
I don't think it's XBR's fault. If it isn't read the xex's properly, then I'm suprised it's even launching anything. -Doom
No, several people have been reporting XBR freezing issues. I don't think it's anything to do with executable code at all. I'm sure it's something else that's small. The executable is loaded into memory once and stays there, its not read over and over.
To tackle these posts. XeNoN.7 and I have worked together for quite a while. We were using the Modified XEX's on XeDK's before he made the initial release we have never had a problem before hand it is stable on XeDK's and XeNoN.7 made sure to remove any and all security. On that note I made sure I tested with a retail xex hence the only thing done was media flag remove. XBR is the only environment that is causing unstable system operation. I did not test it directly in my lab lol, no but I do have reports from other people that Freeboot at this time though lacking functionality compared to XBR is right now stable. FreeBoot does not have a problem with this also I ruled this problem out by doing account recovery in my test above. XeNoN.7 is right, it has nothing to do with the initial execution of code and it is stored into the memory somewhere along the way the Xbox360 is hanging during a read meaning it could be a memory related issue and it is replicable which means it can be fixed in a small update. This applies to retail game discs as well as modified xex's. Hope that helps:thumbsup:
It's just the initial release so there are slight problems. I've had sound cut out on Raiden IV and thats only a 350mb Live file. If you try to play TrailsHD it will freeze every time as well, thats the only game that I have found to freeze every time. But for the first release you can't hate too much, technically second release since it's the .1 version but still it's more then we had a week ago.
Did you guys map out the bad sectors before flashing your XBR? I heard that caused some trouble. There is an app that does this for you btw.
This is universal. XBR.bin is already a premade image and all it does is accept injects kv and config which is like 17 kb each. If there is anything wrong with XBR then its the developers release that has bugs because XBR.bin IS a kernel it only accepts two files from a nand so even if it had bad blocks you would imediately tell because it wouldn't boot if either config / kv is damaged.
Well It would never hurt to map them in the image with an app and post your results. I could have sworn I read it fixed some problems, but mainly with booting.
What Leo says is correct. The NAND is designed to have BBs from the factory (otherwise yields would suck). As a result it is bigger than stated and when flashing properly the system will seamlessly remap a block at the device level. The filesystem won't care that the block is remapped. Now if you're doing a dumb flash of a generic image to your NAND without accounting for BBs, then part of that image could end up landing on a BB and not being properly written. Depending on what lands where could cause anything from a catastrophic failure (ie no boot) to odd errors and freezes. Redline wrote a basic tool to do BB remapping based on your existing NAND dump, but I don't think all that many people using XBR are using it. -hl718
That is correct. Take any two retail systems. The *filesystem* dumps will be identical. The *raw* dumps (even accounting for any bits that are console specific such as KV) will differ. On a super basic level it goes like this: NAND is advertised with 10 blocks of space. Instead it actually has 12 blocks to account for errors. In the example, each "block" holds one letter. An X represents a bad block. A _ represents an unused space. Xbox A: MICXOSXFT_RO Xbox B: XICROSOXT_MF Now, when the system boots both NANDs will show the exact same data "MICROSOFT" taking up exactly 9 of the 10 available blocks. The remapped blocks are effectively hidden from the file system. Now, if you were to take a RAW dump from Xbox A and flash it to Xbox B without remapping the bad blocks you'd end up with a system that displayed a garbled message. For what it's worth, all flash chips do this. Even the one inside your basic USB stick. So long as you access them through a standard interface, you're fine. Bypass that and you have to deal with the bad blocks yourself. -hl718
Just to chime in. My xenon nand has 0 bad blocks. No need to remap them etc. I still have the freezing/crashing problem. Have tried - *xbr0 *xbr0 with updated rebooterCore/patches/xell *xbr1-1921 *Fat32 hard drives. *HFS+ hard drives *Standard MS drive *Data disks. *Old JTAG wiring *New JTAG wiring *With DVD Drive *Without DVD Drive *Different xextool patches. Obviously there are alot of combinations of the above theat havent been explored. I would really like to remove some of the patches from patches.bin, for example the live/hdd checks. (Keeping the .xex patch only) to see if the problems persist.
Your all not understanding what I am saying. XBR is not a dumped image from any random user. XBR is a dumped image from the developers themselves that they checked over. All your doing is patching 2 files that amount to the size of a text document from your original nand so even if your original nand had bad blocks as long as it wasn't in XBR its fine. Just so everyone knows I checked my NAND and got no bad blocks AND I did the "fix" on XBR and I will flash to my xbox 360 to humor you guys. Also ddxcb that is not enough information. Try the things I listed above and report back with your results and be sure that you are using XBR and NOT FreeBOOT. Also I just found a workaround to the XBR crashing but its sad and contradictory and kind of fucked up (in terms of this shouldn't operate this way) Let me just say one word. Windows ->Vmware -> mac os x. That should be enough hints as to what I am doing but because of competition amoung things I won't release it until I know for sure that an update for XBR is coming out soon, if not I may but its a bastardised way of loading. Till then I'm going to flash my 360 one more time to humor all of you. I will report back but I know it won't fix anything because I learned some stuff about XBR that tells me for sure its not the nand image.
I don't think it's the image I just think it's the code, and in the newer releases these problems should be addressed. The good thing about FreeBoot vs XBReboot is that they will make each other better. It's still in it's early stages as we can all tell, but like I've said it's more then we had a couple weeks ago. Plus FreeBoot had been out a couple weeks prior to XBReboot, and from my knowledge and the fact that Freeboot people down talk XBR all the time they are separate groups so they will both improve on each other. Heres looking to the future, and lets see what we have out in a month or two. By the way I would suggest a USB lpt flasher, I have yet to get one, but that will be the next thing that I get.
