I'm developing an Azure Function for removing information protection from files using the
MIP SDK v. 1.10.97. After some successfull calls to protect or unprotect files the Azure Function silently crashes with code -1073740791.
This did not happen with version 1.9.X.
Any ideas what's happening here?
Thomas
Related
I have a Windows desktop C++ application that currently uses ::PathCanonicalizeW. As you can see from the documentation, it was introduced in Windows 2000 and is located in shlwapi.dll. In order to support long paths on Win 10+, I need to start using ::PathAllocCanonicalize (or one of it's friends - ::PathCchCanonicalize or ::PathCchCanonicalizeEx).
This function was added in Windows 8, but I still need to support the older OS's. In order to support all OS's, I need to dynamically load ::PathAllocCanonicalize by calling ::LoadLibrary at runtime. The problem is that the documentation doesn't provide the DLL that includes this function.
After doing some searching, I found this documentation that includes all 3 of the new PathCanonicalize functions and it claims that they are in api-ms-win-core-path-l1-1-0.dll. After more searching, it appears that this is not a traditional DLL because there is no file anywhere in the OS with that name. This application has always loaded system libraries using the full path to the file in the system directory (typically C:\Windows\system32) to make sure that it's not loading malicious DLLs, but for this it will be impossible without a physical file to point to.
I have been able to test that calling ::LoadLibrary("api-ms-win-core-path-l1-1-0.dll") does work, but the fact that that documentation mentions UWP worries me. Is there any documentation for the supported way to dynamically load these kinds of functions at runtime in a desktop app? Is there a more secure way to load this DLL?
P.S. This app cannot be deployed with that DLL, and even if it were possible there's no point since any OS that doesn't have that function wouldn't have full support for long paths anyway. Using the documented pathcch.lib would require upgrading the target Windows version. Dropping support for the older OS's is also completely out of the question. The function must be manually dynamically loaded at runtime.
As pointed out by Hans, api-ms-win-core-path-l1-1-0 is known as an API set along with many others starting with api-ms-win-core. Based on the documentation there, it appears that the documentation for PathAllocCanonicalize is incomplete. It should list the API set on that page along with the DLL for desktop apps. Looking at the source on GitHub, it looks like there is a bug with that page and the other pathcch functions where that information is in the header but not rendered onto the page. That header lists api-ms-win-core-path-l1-1-0.dll and KernelBase.dll.
If for some reason I wanted to continue to load the API set instead of KernelBase.dll, ::LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32) worked which would be just as secure as specifying the full path to a DLL in the system32 folder. Note that LOAD_LIBRARY_SEARCH_SYSTEM32 was not supported without KB2533623 on RTM versions of Vista, Windows 7, Server 2008, and Server 2008 R2 so that might not actually be secure on those OS's.
I am trying to submit a UWP Xamarin Forms app to the Windows store. Everything checks out fine locally. I pass the WACK test (Windows Application Certification Kit) both locally as well as during submission. But during the submission process, I get a cryptic 1201 without any additional information. How can I get additional details to fix this issue.
Looking at some of the posts online, I removed ARM and only submitted an x64 bundle. That seemed to work fine the first time. But when I try and update the submission, I am getting error 1201.
Any and all help would be appreciated.
BTW, I am using VS2019, Xamarin Forms 5.0.0.2083
Thanks in advance.
The issue was not on my end but more to do with the idiosyncrasies of submission process in the Windows Store. I still get sporadic issues but I have resolved it with a combination of the following compiler flags:
Setting the Use64BitCompiler msbuild property to avoid memory issues
true
Ensuring that the release build is clean and working
I will update this answer as I learn more in my subsequent submissions.
I'm learning Google Cloud Vision API, but facing some issues. I have completely repeated all the steps from the 'Getting Started' Guide.
download/install google cloud SDK
activate login credentials using gcloud
Set the environment variable GOOGLE_APPLICATION_CREDENTIALS
Install the client library
After that I ran this code and got this error when compiling:
..\cloud.google.com\go\longrunning\autogen\operations_client.go:166:54: cannot use connPool (type "google.golang.org/api/internal".ConnPool) as type *"google.golang.org/grpc".ClientConn in argument to longrunning.NewOperationsClient
Compilation finished with exit code 2
I repeated all the steps over and over and still get this error. Windows 10 is installed on my pc with the latest software updates.
I have NOT changed the code from the tutorial.
Can anyone please tell me why I'm getting this error?
Issue has been fixed.
I just needed to remove conflicting custom imports and re-install Google Vision library.
Well that was a dumb mistake, sorry to bother you.
I have a UWP project included as part of my Xamarin.Forms solution. When running the Windows App Cert Kit locally, it passes without any issues.
When submitting my app to the store, it fails the certification process with the following error:
Error Found:
The supported APIs test detected the following errors:
API FindFirstFileEx in api-ms-win-core-file-l1-2-0.dll is not supported for this application type. PInvoke.Kernel32.dll calls this API.
Impact if not fixed:
Using an API that is not part of the Windows SDK for Windows Store apps violates the Windows Store certification requirements.
How to fix:
Review the error messages to identify the API that is not part of the Windows SDK for Windows Store apps. Please note, apps that are built in a debug configuration or without .NET Native enabled (where applicable) can fail this test as these environments may pull in unsupported APIs. Retest your app in a release configuration, and with .NET Native enabled if applicable.
I have verified that my app runs in Release mode, and have verified my UWP build settings:
I tried contacting Microsoft's Chat support, but was redirected to enter an Incident Report, where I was then redirected to just ask for help on a forum or pay for advanced tech support, so I haven't been able to get any more information about whether this is a valid failure or not.
Based on the documentation found on FindFirstFileEx (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364419(v=vs.85).aspx), it looks like it is supported by Windows Desktop, Store apps, and Windows Phone. My UWP app was submitted to support Desktop and Mobile families, which seems to be included in the supported clients of this function, so it is unclear as to what is causing the failure.
Any ideas on where to go from here?
Update August 14 2017: This problem should now be resolved in the Store. Please try to re-submit your apps if you hit this issue.
This is a problem in the way the WACK scan is running in the Store, and how it integrates with .NET Native.
For some background, Windows doesn't actually have an API named FindFirstFileEx - it doesn't exist. And the way the WACK's supported API scan works is that it looks at all the APIs you call and verifies if one of the following is true:
It's an API exported by another DLL in your package
It's an API explicitly mentioned in the allow-list
In the case of kernel32.dll!FindFirstFileEx, WACK sees that kernel32.dll doesn't exist in your package so it has to check the allow-list. The allow list doesn't mention FindFirstFileEx because it doesn't exist. Here's what does exist:
C:\Program Files (x86)\Windows Kits\10\App Certification Kit>findstr FindFirstFileEx SupportedAPIs-x64.xml
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-1-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-1.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-2.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-downlevel-kernel32-l1-1-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-1-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-1.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-2.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-downlevel-kernel32-l1-1-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="kernel32.dll"/>
<API Name="FindFirstFileExW" ModuleName="kernel32.dll"/>
Note there are a bunch of entries for FindFirstFileExA and FindFirstFileExW, which are the APIs that actually exist. Whenever your app tries to call FindFirstFileEx, it's actually calling one of these instead.
For C / C++ developers, the pre-processor actually replaces FindFirstFileEx with the A or W version based on the existence of the UNICODE macro.
For .NET developers, the JIT runtime (or, in .NET Native's case, the compiler) figures out whether to call the A or W version based on the specifics of the DllImport attribute, such as the values of the CharSet and ExactSpelling properties.
And herein lies the problem - at the moment, WACK in the Store is running on .NET assemblies before the compiler has substituted the non-suffixed version with the correct suffixed version. When you run WACK on your development machine, it correctly checks the assembly after the compiler has made the substitution, so you see no errors.
The first part of the fix (which is in the works) is to add the non-suffixed versions to the allow-list. The second part of the fix is to make sure WACK runs on the post-compiled bits.
I had the same problem. I opened a chat session (from the dev center), as Peter Torr suggested.
Here is the summary:
Me: My app update is stuck because you have a bug in your certification system. See here: UWP app submission failure due to unsupported API FindFirstFileEx (WACK passes locally)
Support: We are aware of the issue, and are working towards a resolution. I apologize for the inconvenience
Me: Ok, I understand that you are working on the bug. But in the meantime, you could let my app pass, right?
Support: We have a temporary workaround. I can get that info for you if you'd like?
... some minutes later ...
Support: Ok so what I'll need you to do is resubmit your package but include this number XXXXXXXXXXX in the notes for cert section. If that does not work and you app fails cert again, submit feedback on the most recent failed cert report and again insert the number there. I've notated your account to reflect this as well
(real number replaced by XXXXXXXXXXX)
Update 1: Just like #jkh, the automatic certification failed again despite of the number. So I posted the number in a certification feedback.
Update 2: Unfortunately, the "solution" did not help. I now have written an e-mail to the one from the chat support (I got his address after the chat). I am not very confident that this helps. But let's see...
Update 3: I also submitted an incident. (This can be done where you normally start a chat session, but use the button "Submit incident" below.)
Update 4: Answer from incident submission:
Thank you for contacting Developer Support. I understand you have failed certification due to Window Store Policy 15.1 per the API error. After further review I wanted to let you know this is a known issue and currently being worked on a fix by engineers. There should be a fix being rolled out soon and ask that you please wait. If the fix is not implemented by Monday I can have this issue looked into further but since this is a global issue I would recommend to wait for the fix to be rolled out. The moment I hear something as it pertains to the fix I will be sure to reach out and ask that you please try again for certification.
Update 5: I re-submitted my update and I am now waiting for the result.
Update 6: Failed again...
Update 7: Response from incident submission: This is still an ongoing issue and have escalated your issue to our Internal team for further investigation to try and bypass this error for you. Once I receive an update I’ll be sure to reach out.
Update 8: Eventually, after re-submitting, the certification process took two days (!), but now my update is in the store. Wow, what a fight...
I'm facing the same problem. Have submitted a certification feedback report, awaiting some response from Microsoft...
After opening a ticket with Microsoft a few weeks ago I have finally been provided a waiver on my account that allowed me to pass the automated certification.
DO NOT RESUBMIT. I had been told to resubmit and provide certification report feedback on that solution. After resubmitting a few times, I received email responses that my submission had been manually passed, but these submissions had been deleted each time that I resubmitted, so my app still had not been pushed through.
One submission with the number you receive from Microsoft support included in the Notes for Certification and the Certification Report Feedback and with a ticket open with Microsoft will eventually get your submission passed.
since the new SDK 1.1 is missing the tutorial for "ASPProviders", i am currently asking myself how i would implement a "azure session state provider" ( this is the path in the "old" SDK: C:\Program Files\Windows Azure SDK\v1.0\Samples\AspProviders )
Related threads:
How does Microsoft Azure handle Session State?
http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/2d1340ed-0ad0-456a-b069-aa6b85672102/
Has anyone an idea or even the old example project and could post some snippets of the config here?
The old samples are here. But here are the caveats:
They are old and have not been updated in a while
There are a few bugs (some the result of underlying changes in the Win Azure since then, other simply bugs)
There are no unit tests, so you will need to either write your own or live with that.
But, it is a starting point if you are interested in using Win Azure storage (tables + blobs).
A version that works is included in the Windows Azure Platform Training Kit (plus a whole lot of other good sample code).
Download the training kit and install it somewhere on your drive, then you should be able to find it at: \Labs\BuildingWebFormAppsWithWindowsAzure\Source\Assets
Don't forget to look at (or copy) the web.config file that configures the providers in: \Labs\BuildingWebFormAppsWithWindowsAzure\Source\Ex1-UsingAzureProviders\End\CS\AzureStore
Its also in the Assets folder for a few of the other examples, but that should work for you.
I just ran across this a few minutes ago since I'm trying to do the same thing as you:
http://azuresqlsession.codeplex.com/