locked
"Random" and uncatchable AccessDeniedException in component DLL

    Question

  • Hello all,

    we are still searching for the cause of seemingly random occurrences of Platform::AccessDeniedExceptions that get thrown when using our SQLite WinRT (Source at https://github.com/doo/SQLite3-WinRT) component from Javascript.

    I tried adding try/catch blocks using a number of different approaches:

    Concurrency::task<Platform::String^>t([this, sql, params]() -> Platform::String^ {
      try {
        StatementPtr statement = PrepareAndBind(sql, params);
        return statement->All();
      } catch (Platform::Exception^ e) {
        lastErrorMsg = (WCHAR*)sqlite3_errmsg16(sqlite);
        throw;
      }
    });
    return Concurrency::create_async([t]() -> Platform::String^ {
      try {
        return t.get();
      } catch (Platform::AccessDeniedException^ e) {
        throwSQLiteError(SQLITE_ERROR);
      }
    });
    

    As well as adding the AccessDeniedException to the inner try/catch:

    return Concurrency::create_async([this, sql, params]() -> Platform::String^ {
      try {
        StatementPtr statement = PrepareAndBind(sql, params);
        return statement->All();
      } catch (Platform::AccessDeniedException^ e) {
        throwSQLiteError(SQLITE_ERROR);
      } catch (Platform::Exception^ e) {
        lastErrorMsg = (WCHAR*)sqlite3_errmsg16(sqlite);
        throw;
      }
    });
    

    We have unit tests that check if exceptions get thrown and handled correctly both by provoking exceptions through invalid SQL commands and throwing exceptions in continuations. And we have made the experience that normally, when an exception is thrown, the debugger immediately reacts to it as a first chance exception and breaks at the line where it occurs.

    But in this case, even setting a breakpoint in the catch clause for AccessDeniedExceptions doesn't do a thing and the exception still gets thrown and crashes the app.

    Also, when digging through the callstack, in 
    SQLite3.dll!Windows::Foundation::AsyncOperationCompletedHandler<SQLite3::Database ^ __ptr64>::NonVInvoke(Windows::Foundation::IAsyncOperation<SQLite3::Database ^> ^ __param0, Windows::Foundation::AsyncStatus __param1)
    it looks like the exception can occur even for promises that did complete successfully.

    So, having said all that, I'm perplexed as to the cause of these exceptions. I should also mention that we're using an in-memory database for testing so it can't be related to file access which I understand is a common cause for these exceptions.

    Any help and tips are welcome. 
    All the best
    Marcus

    Tuesday, August 21, 2012 8:06 AM

Answers

  • Thanks Marcus. In your repro I traced it as far back as the JavaScript engine, at which point I was out of my element so I opened a bug for the JavaScript team to investigate. I'll let you know of any new developments.

    David Lamb

    • Marked as answer by Marcus Ilgner Wednesday, August 29, 2012 3:06 PM
    Tuesday, August 28, 2012 11:09 PM
    Moderator

All replies

  • Something I forgot to mention: it is easy to provoke this exception by navigating to another page.

    This led me to this working theory - which, since I don't have any knowledge about the inner workings of the WWAHost or the JavaScript engine, might be totally bogus:

    Maybe the JavaScript starts a call into the native component which opens a second thread and keeps a pointer to the Javascript completion handler - which to me looks like a weak reference judging from the name '__weakRefSource' in __abi_reference_count. While the native async action is running, the page navigates somewhere else and for some reason or other, the Javascript engine decides to garbage collect any unused objects (the promises aren't referenced anywhere at this point).

    Now when the native async action completes its work, it tries to call the JS handler but finds that the object has been removed or is invalid in some way and throws an exception.

    Edit: I have created a branch which allows easy reproduction of the exception. You can find it at https://github.com/doo/SQLite3-WinRT/tree/access_denied_exception

    • Edited by Marcus Ilgner Tuesday, August 21, 2012 11:31 AM Add link for reproducing code
    Tuesday, August 21, 2012 9:13 AM
  • Another follow-up: I extracted the code from the disassembly which calls the method that returns the HRESULT and put it into the ticket over at our repository.
    Thursday, August 23, 2012 9:20 AM
  • Hi Marcus,

    I wanted to clarify one point. Is this problem specific to consumption from a JavaScript app (i.e. have you had the time to verify this does not occur when using a .Net or C++/CX client app)?

    You also mention it is crashing the app. If you have a crash dump to investigate, please email me to arrange logistics of getting it over to us for review. DavidLam AT Microsoft DOT COM. This thread has the registry settings you can use to capture a full process dump.

    Thanks!


    David Lamb

    Thursday, August 23, 2012 11:55 PM
    Moderator
  • Hello David,

    thank you for getting back to me, I really appreciate it. So far I didn't test the component with a C++ app since I'm not familiar with the XAML API and don't know how I can do something like the navigation event I use to reproduce the error in a JavaScript host.

    From all I can tell though, it looks very specific to JavaScript. I tried creating some C++ unit tests but as the component uses the dispatcher from the CoreWindow to run callbacks in the main application, which isn't available during headless unit tests, that didn't work out.

    I have however successfully created a crash dump and will send you a link to download it.

    Friday, August 24, 2012 11:58 AM
  • Thanks Marcus. In your repro I traced it as far back as the JavaScript engine, at which point I was out of my element so I opened a bug for the JavaScript team to investigate. I'll let you know of any new developments.

    David Lamb

    • Marked as answer by Marcus Ilgner Wednesday, August 29, 2012 3:06 PM
    Tuesday, August 28, 2012 11:09 PM
    Moderator