Friday, April 23, 2010

Development on retail 360

Developping on a retail 360 is a real pain. The default behavior of the 360 on an unhandled exception is to freeze... just freeze... Need to cold reboot the xbox, rebuild a version that may be fixed, transfer using a stable software, test and if youre lucky your freeze is gone.

There's way to make this issue more bearable :
Define an unhandled exception filter :
LONG WINAPI UnHandleExceptionFilter(struct _EXCEPTION_POINTERS *lpExceptionInfo) {}

Then first line in you main fuction  :
SetUnhandledExceptionFilter(UnHandleExceptionFilter);

Now, instead of freezing, your UnHandleExceptionFilter method will be called, if the function return EXCEPTION_CONTINUE_EXECUTION then execution of software continue, but thread that crashed is still stopped, meaning that if your GUI thread throwed the exception , even if you ask to continue, you are pretty much screwed (can still have a network listener running). So exception are "No Continuable" : returning EXCEPTION_CONTINUE_EXECUTION on those will just rethrow another exception and may totally freeze the 360.

Our current solution is to have a XShowMessageBoxUI displayed in the filter method. The msg box have 3 options : Restart FSD, Go Back to NXE, Try to continue.
If no options are selected within 20 seconds, we restart FSD (most of the time, GUI Thread has crashed, then XShowMessageBoxUI  wont display anything).

So we dont have to reboot at every exception, but finding those are a real chore : we need to disables each module 1 by 1, trying to figure out which one cause the crash. When we found the module, we need to find what happened in the module.... makes the whole software a Debug Log Party!

One thing you can do to help pinpoint the exceptions : the struct you receive in the filter does contain an exception code (lpExceptionInfo->ExceptionRecord->ExceptionCode) but they sometime are really strange: been having a lot of EXCEPTION_BREAKPOINT... which obviously I didnt hit a breakpoint!

Those random crash are a real pain in the a** to fix... having an XDK would so much help!!

You can get our exeption handling code here :
http://tinypaste.com/260814

You'll then just need to add SetUnhandledExceptionFilter(UnHandleExceptionFilter); in your main and change the DebugMsg, Restart and BackToNxe methods!

5 comments:

  1. Dude, thank you sooo much, I have been struggling with trying to debug with a non dev console.

    ReplyDelete
  2. Donation headed your way. Thanks, keep up the hard work.

    ReplyDelete
  3. Thx! I hope this info can help lots of developer. I was expecting to release our complete debug solution (auto xex deploy, auto skin deploy, tabbed live debug log on pc, send command from pc to xbox) but we recently found some bug in our pc software that need to be fixed before we release.

    ReplyDelete
  4. EXCEPTION_BREAKPOINT is used on things like sprintf when you feed it overflow or similar. I too thought it was very strange until I used full exception information to find the breakpoint address then looked in the disasm.

    ReplyDelete