null_pointer_read in windows.storage.onecore.dll

[FrayxRulez]

Hello, not sure if this is the right repository, but well. I have a UWP app with some core parts written in C++, this parts of the app make heavy use of file system APIs. Recently I decided to move to *FromApp variants of the APIs, as the app downloads quite a lot of files from the web and I wanted to give to the users the ability to change default download location (By using FolderPicker and StorageApplicationPermission.MostRecentlyUsedList). Now everything seems to work pretty much ok, but I started to see in dev center Health page a rising amount of null_pointer_read exceptions raised by windows.storage.onecore.dll.

Here's the stack trace:

Frame   Image   Function    Offset
0   Windows.Storage.OneCore.dll WindowsStorage::Utilities::NamespaceMap_AccessListReadCache::CacheItem *,NtPathDelimiter_::FindAll  0x000000000000016A  
1   Windows.Storage.OneCore.dll WindowsStorage::Utilities::NamespaceMap_AccessListReadCache::CacheItem *,NtPathDelimiter_::FindAll  0x00000000000001D4  
2   Windows.Storage.OneCore.dll WindowsStorage::Utilities::NamespaceMap_AccessListReadCache::CacheItem *,NtPathDelimiter_::FindAll  0x00000000000001D4  
3   Windows.Storage.OneCore.dll AccessListReadCache::Contains   0x0000000000000067  
4   Windows.Storage.OneCore.dll WindowsStorage::Win32BrokeredAPIs::FilePathAccess::IsAllowed    0x000000000000030E  
5   Windows.Storage.OneCore.dll WindowsStorage::Win32BrokeredAPIs::FilePathAccess::IsAllowed    0x00000000000000C2  
6   Windows.Storage.OneCore.dll CWin32Broker::CreateDirectoryW  0x000000000000011A  
7   rpcrt4.dll  Invoke  0x0000000000000073  
8   rpcrt4.dll  Ndr64StubWorker 0x0000000000000B07  
9   rpcrt4.dll  NdrStubCall3    0x00000000000000C9  
10  combase.dll CStdStubBuffer_Invoke   0x0000000000000060  
11  rpcrt4.dll  CStdStubBuffer_Invoke   0x000000000000003B  
12  combase.dll ObjectMethodExceptionHandlingAction__lambda_c9f3956a20c9da92a64affc24fdd69ec_ _ 0x0000000000000043  
13  combase.dll DefaultStubInvoke   0x00000000000001EE  
14  combase.dll SyncServerCall::StubInvoke  0x0000000000000026  
15  combase.dll ServerCall::ContextInvoke   0x0000000000000403  
16  combase.dll DefaultInvokeInApartment    0x00000000000000AD  
17  combase.dll ComInvokeWithLockAndIPID    0x0000000000000BC4  
18  combase.dll ThreadInvokeWorker  0x00000000000007C4  
19  combase.dll ThreadInvoke    0x0000000000000009  
20  rpcrt4.dll  DispatchToStubInCNoAvrf 0x0000000000000018  
21  rpcrt4.dll  RPC_INTERFACE::DispatchToStubWorker 0x00000000000001A6  
22  rpcrt4.dll  RPC_INTERFACE::DispatchToStubWithObject 0x0000000000000186  
23  rpcrt4.dll  LRPC_SCALL::DispatchRequest 0x000000000000016F  
24  rpcrt4.dll  LRPC_SCALL::HandleRequest   0x0000000000000808  
25  rpcrt4.dll  LRPC_ADDRESS::HandleRequest 0x0000000000000341  
26  rpcrt4.dll  LRPC_ADDRESS::ProcessIO 0x000000000000089A  
27  rpcrt4.dll  LrpcIoComplete  0x00000000000000C2  
28  ntdll.dll   TppAlpcpExecuteCallback 0x0000000000000260  
29  ntdll.dll   TppWorkerThread 0x000000000000044C  
30  ntdll.dll   RtlUserThreadStart  0x000000000000002F  

[AvriMSFT]

@FrayxRulez I've filed a bug on the team who owns the file. They might reach out to inquire a bit more about the scenario. I'll check in on this thread with updates as they roll in.

[FrayxRulez]

Hi Avri, sounds great! Thank you 😄

[smaillet-ms]

Can you provide some more context/detailed repro steps for hitting this? What OS version? (full build version please) What process is this from? (We may be able to find telemetry from failures in these APIs that indicate what's going on but it would help to filter on the process name.) Do you know the path of the directory passed to CreateDirectoryFromApp() - especially important is any whitespace or trailing characters as I think this is a duplicate of a known bug that was fixed already but will need some help from you to verify.

[FrayxRulez]

Hi @smaillet-ms, I'm actually seeing this behavior in production only. Path is arbitrarily picked by users so I don't have any details about it. In addition to the crash in FindAll, I can see one in Insert as well. I can see some thousands of this crashes from the Partner Center, and some of them even have a crash dump. Process name is Unigram.exe. Unfortunately I can't provide any more information, I fear. What I do on app boot is to retrieve the folder that the user picked as download location for the app using StorageApplicationPermissions.MostRecentlyUsedList.GetFolderAsync, the path is then passed to our standard C++ library that is going to invoke CreateDirectoryFromApp few times to create subfolders in it ("photos", "videos", "documents", and so on)

[smaillet-ms]

FYI - we are investigating, I think this is related to a bug we fixed already, but hasn't made it out through the release pipeline yet. Can you contact me directly [smaillet - microsoft - com] so we can get details and business justifications for servicing down-level OS versions?

[AvriMSFT]

@smaillet-ms Sounds like this conversation was taken offline. Any updates to report here?