Instead of my usual litany of woe and rails against all things that don't work to my immediate satisfaction, I thought would post today on something that WAS an issue. And, no longer is a problem.
One of the application compatibility issues that raised an issue prior to the release of App-V 4.5 Cumulative 1 (CU1) is detailed in the following post from Just Zarb
"An application compatibility" problem occurs when an unmanaged executable file (.exe) is statically linked to a managed module (.dll/.lib). "
When the .exe file is unmanaged, sftldr.dll gets loaded just after ntdll.dll, and kernel32.dll file.
After that, if the loader finds any dependent managed module during the implicit loading phase , it tries to validate that image using _CorValidateImage() function of mscoree.dll.
_CorValidateImage() performs the following 2 actions:
1. Ensures that the code is valid managed code.
2. Changes the entry point in the image to an entry point in the runtime.
_CorValidateImage() calls all the dllMain() function of modules that got loaded before this managed module, and the dllMain() of sftldr.dll also gets called.
This may result in the wrong version for desired loading or worse, not loading the required DLL at all. The likely result here is that the application will fail to start.
This problem does not happen when both the .exe file and the dll module are managed. When the .exe file is managed, mscoree.dll module gets loaded before sftldr.dll.
Now, the good news is that this issue has been resolveD and verified by the good folks in the Microsoft Premier Field Engineering (PFE) team with the release of App-V CU1.
See, my blog is not so bad after all...
References:
Justin Zarb's blog (The World Simplified is a Virtual World)
You can find Microsoft's App-V 4.5 CU1 update here:
Read about Microsoft "Managed Execution Process"
No comments:
Post a Comment