Your solution/workaround solves the error.
Thank you very much.
""Jeffrey Tan[MSFT]"" wrote:
> Hi Friedhelm,
>
> Based on my search in our internal database, I find a known issue regarding
> statically linking winmm.dll resulted in "The application failed to
> initialize properly - 0xc0000005", I suspect this is the same issue as
> yours.
>
> Based on the bug record, the entry point(DllMain) of winmm is calling
> FreeLibrary. However, calling FreeLibrary is a danger operation which may
> cause the Access Violation error. This warning/rule has been documented in
> the SDK link below:
> "Dynamic-Link Library Entry-Point Function"
>
http://msdn2.microsoft.com/en-us/library/ms682596.aspx >
> To workaround this issue, do not link your application with WINMM, but
> instead use LoadLibrary to import the function at runtime.
>
> An application does this by calling the LoadLibrary function to load the
> DLL and then calling the GetProcAddress function to retrieve the address of
> the required function. The application should
> check the values returned from LoadLibrary and from GetProcAddress to
> ensure that these functions succeed. If the DLL is not found or does not
> export the desired function, one of these calls fails, and the
> application can handle the error gracefully.
>
> Additionally, if you want to know how to debug such type of crash in
> production environment, you may refer my blog entry below(I wrote this blog
> entry for our team's blog):
> "How to debug application crash/hang in production environment?"
>
http://blogs.msdn.com/msdnts/archive/2006/11/24/how-to-debug-application-cra > sh-hang-in-production-environment.aspx
>
> Hope this helps.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> ==================================================
> Get notification to my posts through email? Please refer to
>
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
>
http://msdn.microsoft.com/subscriptions/support/default.aspx. > ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>