1
Vote

Making sure the debughandler callback is empty

description

Hello,
We are getting all the output from the XB1 using the following :
                EventHandler<TextEventArgs> l_debugHandler = null;
                //Callback used to get some debug information from the console directly in the console output
                l_debugHandler = (Object sender, TextEventArgs e) =>
                {
                    Console.Write("{0}", e.Message);
                };
This is really useful for us, however as specified in the documentation, this can only be attached when the package is running.
So we are doing the following :
                    l_xbPackageApp.Launch(args);
                    Console.WriteLine("Successful!");
                    XboxProcess l_runningProcess = l_xbConsole.GetRunningProcesses(XboxOperatingSystem.Title).Single(p => p.ImageFileName.Contains(executableName));
                    Console.WriteLine("*****************************START CONSOLE OUTPUT************************************************");
                    l_runningProcess.TextReceived += l_debugHandler;
                    l_packageRunningWaitHandle.WaitOne();
Because of this, we sometime miss the first output information from the game.

Also, because there is no way of knowing if there is still some pending calls on the debug handler, we never unregister it
//We are not unregistering the callback as it triggers an assert because the process is not running anymore
//l_runningProcess.TextReceived -= l_debugHandler;

and we have to wait an arbitrary number of seconds once the game ended to make sure we have all the last debug output from the kit, before we can unregister the package.

comments

amccalib wrote May 18, 2015 at 7:19 AM

Sorry for the delay.

I agree with your first concern. When the Xtf feature to subscribe to debug output was first introduced, we suggested it would be better if we could subscribe prior to creation, thereby getting all output. Unfortunately, we're still waiting on that to be implemented.

I'll look into the unsubscribe behavior you call out. At the very least, we could probably be handling the missing process exception more gracefully.

wrote May 18, 2015 at 7:19 AM