locked
Why does Windows.Storage.ApplicationData.current.localFolder raises an Exception?

    Question

  • I get this exception, when running the app in native debugging mode:

    First-chance exception at 0x000007FADCAB8FDA (KernelBase.dll) in WWAHost.exe: 0x40080201: WinRT originate error (parameters: 0x000000008000000B, 0x0000000000000040, 0x000000160AB3E730).

    when this line of JS code is executed:

    (function() {
      var localFolder = Windows.Storage.ApplicationData.current.localFolder;
    }).call(this);

    This is the callstack:

    >	KernelBase.dll!RaiseException()	Unknown
     	combase.dll!`Microsoft::WRL::Module<1,class Microsoft::WRL::Details::DefaultModule<1> >::Create(void)'::`2'::`dynamic atexit destructor for 'module''(void)	Unknown
     	WinTypes.dll!Windows::Foundation::Collections::Internal::HashMap<HSTRING__ * __ptr64,IInspectable * __ptr64,Windows::Foundation::Collections::Internal::DefaultHash<HSTRING__ * __ptr64>,Windows::Foundation::Collections::Internal::DefaultEqualityPredicate<HSTRING__ * __ptr64>,Windows::Foundation::Collections::Internal::DefaultLifetimeTraits<HSTRING__ * __ptr64>,Windows::Foundation::Collections::Internal::DefaultLifetimeTraits<IInspectable * __ptr64>,Windows::Foundation::Collections::Internal::HashMapOptions<HSTRING__ * __ptr64,IInspectable * __ptr64,Windows::Foundation::Collections::Internal::DefaultLifetimeTraits<HSTRING__ * __ptr64>,1> >::Lookup(HSTRING__ * key, IInspectable * * value) Line 3734	C++
     	Windows.Storage.ApplicationData.dll!Windows::Internal::StaticLifetimeStore::Read(Windows::ApplicationModel::Core::ICoreApplication * coreApp, const wchar_t * value, unsigned char) Line 131	C++
     	Windows.Storage.ApplicationData.dll!Windows::Storage::ApplicationDataFactoryServer::get_Current(Windows::Storage::IApplicationData * * value) Line 60	C++
     	rpcrt4.dll!Invoke()	Unknown
     	rpcrt4.dll!Ndr64StubWorker(void *,void *,struct _RPC_MESSAGE *,struct _MIDL_SERVER_INFO_ *,long (*const *)(void),struct _MIDL_SYNTAX_INFO *,unsigned long *)	Unknown


    • Edited by phil_ke Tuesday, April 17, 2012 4:03 PM changed title
    Tuesday, April 17, 2012 4:02 PM

Answers

  • Do you get a Javascript exception when running under the script debugger?  If not, this is probably an error that is generated and handled by the WinRT component code, before returning to your app code.  Any failures returning from WinRT to Javascript are exposed as Javascript exceptions.

    • Marked as answer by phil_ke Wednesday, April 18, 2012 1:07 PM
    Tuesday, April 17, 2012 4:45 PM

All replies

  • What is (this) in this context?

    Jeff Sanders (MSFT)

    Tuesday, April 17, 2012 4:38 PM
    Moderator
  • the Window object I suppose. Its the standard way to declare JS code and not pollute the global namespace. Just imagine this code in a js file that is included via script tags in the default.html

    Tuesday, April 17, 2012 4:43 PM
  • Thanks Phil, I will look into more specifics of call() since I have not used it before.

    Jeff Sanders (MSFT)

    Tuesday, April 17, 2012 4:45 PM
    Moderator
  • Do you get a Javascript exception when running under the script debugger?  If not, this is probably an error that is generated and handled by the WinRT component code, before returning to your app code.  Any failures returning from WinRT to Javascript are exposed as Javascript exceptions.

    • Marked as answer by phil_ke Wednesday, April 18, 2012 1:07 PM
    Tuesday, April 17, 2012 4:45 PM
  • The Exception is not thrown in the JS debugger, and thats what worries me :)

    Note: The execption is always thrown when Windows.Storage.ApplicationData.current.localFolder is used anyway in the script code. 

    • Edited by phil_ke Tuesday, April 17, 2012 4:49 PM
    Tuesday, April 17, 2012 4:47 PM
  • As an aside we pattern the annonymous functions througout our templates.  It is not  necessary for .call to create these functions hence my confusion.

    I think I get it now, you are declaring the function and immediately calling it correct?


    Jeff Sanders (MSFT)


    Tuesday, April 17, 2012 5:00 PM
    Moderator
  • The exception above is a first-chance exception that is always thrown whenever a WinRT component calls OriginateError, which associates additional error information with an error.  Specifically, the component is associating error information with an E_BOUNDS HRESULT (0x8000000B).  In this case, get_Current has special behavior to handle this error and return a valid result.  If a call to a WinRT component ever fails, you will get a Javascript exception.  While native first-chance exceptions are useful for debugging your own components, it is usually safe to ignore them, especially WinRT Originate Error exceptions, when they do not result in a Javascript exception.

    Tuesday, April 17, 2012 5:11 PM
  • A thanks, Caroline. This is good to know. I will ignore those kind of exceptions from now on. This seems to be part of the workflow inside the WinRT component that provides access to the apps local folder.
    Wednesday, April 18, 2012 1:08 PM