The impact of asynchronous operations on debugging

    General discussion

  • In this thread cdunford brings up a good point: "I'm not sure what we're going to be able to do when we get the inevitable crash dumps from WinQual that show nothing but XAML and WinRT functions in the call stack."

    Of course, it's not just crash dumps. Maybe I've missed something, but Debugging C++ in Visual Studio isn't up to par, yet. Try throwing this in your project somewhere:

    		task<StorageFile^> getStorageFileTask = task<StorageFile^>(StorageFile::GetFileFromPathAsync(L"*"));

    Wait a week so you forget where you put it, and then see how long it takes you to find the source of the Platform::COMException^ that'll surely appear. The call stack won't help (example). Stepping through barely helps. Printf won't help. Only way I can see to tease it out is essentially commenting out bits of your project until things aren't broken anymore.

    I don't like to complain without offering at least an idea: Have IAsynOperation (and task<> for that matter) save the instruction pointer of the first stack frame that doesn't belong to the crt, ppl library etc. Since walking the stack is expensive, save the IP before leaving user code, and pass it down to all subroutines that might need it. Perhaps a compiler extension that does it transparently with functions marked with a special attribute? These functions have an intrinsic to retrieve the IP of the latest user code which doesn't have that special attribute. The performance might be good enough to even keep it in release code. Maybe there can be a compiler flag that saves the entire stack frame and registers so the debugger can show the whole call stack and local variables and parameters. Discard that information when an async task ends, and hopefully the memory footprint won't be too bad (since the performance will be terrible! ha)

    Thursday, April 19, 2012 6:03 PM

All replies

  • I think we should get the error message from WRL layer. 


    Friday, April 20, 2012 5:47 AM