When are you planning to update UTC module to latest? This is required due to compliance reasons on Win 10. Is it possible to adjust your build system to use precisely matching versions of compiler+toolset+sdk version? (to avoid 1-1-0 vs 1-2-0 mismatch, that is clearly happening since you are building different parts of your build with different dependencies). Thus, whatever function that calls into load library (could be related to Runtime Object activation) itself will not be you clarify on this: To me it looks like NOT a bug in SDK, but a build / deployment mismatch in your build system.Īlso you can try to /DELAYLOAD - API-MS-WIN-CORE-LIBRARYLOADER-L1-2-0 - UTC code needing it is not gonna be executed on Windows 7, because it lives behind a Windows version check. Unfortunately none of this would apply to a year-old old snapshot of 1DS SDK. vcxproj files on your older build to explicitly specify the toolset / runtime / Win 10 SDK version to match what your product is using, making sure that both are built with the same compiler? These customizations are now more easily implemented in our latest master branch, where we provide ability for product teams to override MSBuild props. dll a possibility? Can you investigate an option of customizing the. Just copying this dll from manual download fixes the problem can elaborate on - could you please clarify on this: These fixes will be necessary for some data compliance / tagging / provider group id associations of your critical / core data events. So turning this code off with a conditional compilation should resolve the issue for you, without any additional side-effects at - you will 100% need to upgrade to latest UTC module since there were fixes deployed in that by Windows Fundamentals team. Historically we know that you do not emit events larger than 64KB. This won't affect you anyhow, because that feature is only needed for RS5+ versions of Windows, and only if you emit events larger than 64KB. We can avoid the failure by NOT using this dll loading feature in UTC module. dll from APISets that you are eventually not deploying on target. your PRODUCT are built with different version of Win 10 SDK, different version of toolset / compiler, and that results in the static SDK library to be using a different (more recent) version of the LibLoader. That is the only function loaded from libloader.dll The only place that invokes LoadLibraryExW call in SDK is in the UTC module, the place I am showing above. I have build the same code without UTC code and don't have this issue.Īnd only fails when you add UTC module functionality. In your original bug report, you guys mentioned that the build works fine without UTC: Possibly you are using some custom version of the compiler toolchain.Īre you sure that it is the LoadLibraryExW call that is causing the problem? Do you see the issue with that? If you don't, then there is some unique combination of build artifacts in your product that is breaking the standard loader / dynamic linker functionality. Do you see the issue with a standard sample app included in our Visual Studio solution? Build MSTelemetrySDK.sln - SampleCppUTC and run it. Please also confirm that your Platform is indeed Windows 10. Try to remove the older Windows 7 or 8 SDK from your build path. One explanation I have as to why this is not happening for you - you are possibly mixing the implementation of the loader with some code from older Windows SDK. dll dependencies, similar to that:ĪPI-MS-WIN-CORE-LIBRARYLOADER-L1-2-0.DLL should be aliased by linker to KernelBase.dll. Then use this tool: to obtain a screenshot of your. Would you mind providing additional information? Please make sure that you have the latest VC redist installed first using the link above.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |