locked
[UWP][C++/CX] How to debug a test packaged App RRS feed

  • Question

  • Hello, 

    I have an Windows 10 UWP desktop application that works well when built with Visual Studio. When the application is put into a test package and installed via PowerShell on another Windows 10 system, the application crashes and I have no visible debug. Is there any way to know why it has crashed?

    Friday, October 7, 2016 6:48 PM

Answers

  • Heyo SFL-Andreas, I would try adding a listener to the UnhandledException event that gets fired at the Application level. In there you can mark the crash as handled and use the opportunity to write the exception information to a text file.

    Something like :

    using namespace concurrency;
    ...
    
    void App::OnUnhandledException(Platform::Object^ sender, Windows::UI::Xaml::UnhandledExceptionEventArgs^ e)
    {
    	// marking the exception as handled will prevent the crash
    	e->Handled = true;
    
    	// write the exception message out to a text file
    	auto writeFolder = Windows::Storage::ApplicationData::Current->LocalFolder;
    	create_task(writeFolder->CreateFileAsync("CrashInfo.txt", Windows::Storage::CreationCollisionOption::ReplaceExisting))
    		.then([=](Windows::Storage::StorageFile^ file)
    	{
    		create_task(Windows::Storage::FileIO::WriteTextAsync(file, e->Message)).then([=](void)
    		{
    			// the file has successfully been written, now crash like we would have
    			std::string zero = "0"; // get around compiler warnings
    			int i = 1 / atoi(zero.data()); // Still crash anyways
    		});
    	});
    }

    Then when you deploy through the PowerShell, when you trigger the crash, you can go looking for the dump file for information about the exception that was thrown.
    The LocalFolder is located at  "C:\Users\{userprofile}\AppData\Local\Packages\{packagenameguid}\LocalState\" You can find the package name guid in the Package.appxmanifest under the Packaging tab.

    Hope this helps!
    ~Kyler


    • Edited by Kyler Mulherin Saturday, October 8, 2016 12:36 AM Updated output path
    • Proposed as answer by David_FF Thursday, October 13, 2016 8:46 PM
    • Marked as answer by Barry Wang Friday, October 21, 2016 6:04 AM
    Saturday, October 8, 2016 12:35 AM

All replies

  • Heyo SFL-Andreas, I would try adding a listener to the UnhandledException event that gets fired at the Application level. In there you can mark the crash as handled and use the opportunity to write the exception information to a text file.

    Something like :

    using namespace concurrency;
    ...
    
    void App::OnUnhandledException(Platform::Object^ sender, Windows::UI::Xaml::UnhandledExceptionEventArgs^ e)
    {
    	// marking the exception as handled will prevent the crash
    	e->Handled = true;
    
    	// write the exception message out to a text file
    	auto writeFolder = Windows::Storage::ApplicationData::Current->LocalFolder;
    	create_task(writeFolder->CreateFileAsync("CrashInfo.txt", Windows::Storage::CreationCollisionOption::ReplaceExisting))
    		.then([=](Windows::Storage::StorageFile^ file)
    	{
    		create_task(Windows::Storage::FileIO::WriteTextAsync(file, e->Message)).then([=](void)
    		{
    			// the file has successfully been written, now crash like we would have
    			std::string zero = "0"; // get around compiler warnings
    			int i = 1 / atoi(zero.data()); // Still crash anyways
    		});
    	});
    }

    Then when you deploy through the PowerShell, when you trigger the crash, you can go looking for the dump file for information about the exception that was thrown.
    The LocalFolder is located at  "C:\Users\{userprofile}\AppData\Local\Packages\{packagenameguid}\LocalState\" You can find the package name guid in the Package.appxmanifest under the Packaging tab.

    Hope this helps!
    ~Kyler


    • Edited by Kyler Mulherin Saturday, October 8, 2016 12:36 AM Updated output path
    • Proposed as answer by David_FF Thursday, October 13, 2016 8:46 PM
    • Marked as answer by Barry Wang Friday, October 21, 2016 6:04 AM
    Saturday, October 8, 2016 12:35 AM
  • Thank you Kyler! I will give it a shot ASAP and give some feedback!

    However, I tried running the app through the windows certification test. It failed horribly because of API violations. Which sucks because I don't understand why the development environment would allow me to get so far without flagging these API violations. Essentially, I find it unclear as to why it would work on systems with Windows SDKs installed and not others.

    Thanks, I'll get back to you!

    -Andreas

    Monday, October 10, 2016 6:26 PM
  • Hi Kyler,

    The crash is occurring before the Application is constructed, so I won't be able to see the error report. The UnhandledExceptionHandler will definitely be useful, once I find a way to resolve the 94 API violations in the App. I'm gonna start a new thread regarding API violations.

    Thanks for your help

    -Andreas

    Tuesday, October 11, 2016 3:00 PM