Bug #33031 app linked to libmysql.lib crash if run as service in vista under localsystem
Submitted: 6 Dec 2007 7:03 Modified: 23 Oct 2008 2:18
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: C API (client library) Severity:S1 (Critical)
Version:5.0.50 OS:Windows (Vista Business Edition)
Assigned to: Vladislav Vaintroub CPU Architecture:Any
Tags: crash, service, vista

[6 Dec 2007 7:03] Shane Bester
Description:
if an application meets all of the following requirements, a crash is seen during starting the service:

o) run on windows vista
o) link with libmysql.lib,log4cxx.lib (in that order)
o) run as a service
o) run as localsystem account
o) call mysql_init()

If run in command line mode, no crash is seen.
If linked in different order log4cxx.lib,libmysql.lib no crash is seen.
If Administrator account is used instead of localsystemno crash.
If run on XP or 2003, no crash is seen.

So it seems specific to Vista, and all the items listed above.

Below is all the crash information I could get from when the service failed to start.

Problem signature:
Problem Event Name: APPCRASH
Application Name: myService.exe
Application Version: 0.0.0.0
Application Timestamp: 474fe464
Fault Module Name: StackHash_e51a
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 00000000
OS Version: 6.0.6000.2.0.0.256.6
Locale ID: 7177
Additional Information 1: e51a
Additional Information 2: 4c0d4d78887f76d971d5d00f1f20a433
Additional Information 3: e51a
Additional Information 4: 4c0d4d78887f76d971d5d00f1f20a433

How to repeat:
uploading testcase in private file.
[6 Dec 2007 7:03] MySQL Verification Team
Need second opinion of some Vista expert here before setting verified.
[17 Dec 2007 10:01] Olivier Cante
I found exactly the same problem. 
Even if the UAC is off, the problem still occurs.

Has anybody found a solution ?
Is there a new version of libmysql which works under Vista ?
[17 Dec 2007 10:16] Valeriy Kravchuk
Bug #33285 was marked as a duplicate of this one.
[21 Dec 2007 6:51] Tonci Grgin
Olivier, unfortunately this is not an easy bud to figure out but we are working on it.
[6 Mar 2008 11:45] Neil Evans
Thanks for reporting this Shane, we're having the same problem on Vista too.

Running MySQL 5.0.45

Our Service is compiled in Borland c++ 6, linked with libmysql.lib only.
Runs fine in command line.
Tried localsystem, Administrator, other user accounts, still crashes on mysql_init() on Vista.

This does not occur on any other NT platform, neither on linux where I use libmysqlclient.a to link.

Doing a try..catch to try and exit with manners on exception is useless too.
[18 Mar 2008 1:24] Matthew Paulson
MS support claims that this is happening because the dll is initing winsock from dllmain, which they claim is a "no no".

- Matt Paulson  paulson@busiq.com
[19 Mar 2008 13:45] Laurent TUREK
Hi,
We're having the same problem on Windows Server 2008.
We're running MySQL 5.0.50 sp1 enterprise.

Our Service is compiled with Visual C++ 98, linked with libmysql.lib (first listed) and many others libs.

This does not occur on any other NT platform, neither on linux where we use
libmysqlclient.a to link.

If we link with libmysql.lib in last position, the problem does not occur...

Maybe it will be helpful...
[19 Mar 2008 13:52] Matthew Paulson
I solved the problem by statically linking the client code by using mysqlclient.lib rather than libmysql.lib.  The former contains all the dll code, so it gets statically linked to you application.  The later is a stub lib that causes the dll (libmysql.dll) to get loaded at which time, which according to MS, is a problem, since the dll initializes winsock from dllmain().

-- Matt
[20 May 2008 7:50] Tonci Grgin
Matthew, thank you for your analysis.
[20 May 2008 13:21] Tonci Grgin
Shane, I'll set this to "Verified" but only on certain aspects:
  - "o) link with libmysql.lib,log4cxx.lib (in that order)": 
Quoting wlad: One cannot simply build log4cxx 0.9.7 It is using "#import <msxml.dll>" and this dll is no more present(http://www.nabble.com/Problems-with-msxml-for-log4cxx-on-Vista-td12764184.html). So I just commented out all log4cxx stuff in the sample program and wonder, everything worked OK. Also I'm a bit skeptic about the state of log4cxx- their latest (alpha?/beta?) release 0.9.7 is 4 years old and the library has *never* been officially released.
I'm still guessing what the alone presence of log4cxx might break, there is no usage of it in the sample program. Might be C++ static object initialization. Might be somehow related to msxml.dll that is not present.

And Miguel: We should use msxml6.dll,available in Platform SDK feb CTP. So I agree with Vlad regarding we need an update library for that.

There are also posts from Matthew to be taken into account. His last post provides acceptable workaround, Thanks.
[19 Aug 2008 15:46] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/51978

2666 Vladislav Vaintroub	2008-08-19
      his patch fixes
      Bug#37226 Explicit call of my_thread_init() on Windows for every new thread.
      Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
      localsystem
      Bug#38522 5 seconds delay when closing application using embedded server
      
      There are some problems using DllMain hook functions on Windows that 
      automatically do global and per-thread initialization for a DLL in MySQL context
      
      1)per-thread initialization(DLL_THREAD_ATTACH)
      MySQL internally counts number of active threads that and causes a delay in in 
      my_end() if not all threads are exited. But,there are threads that can be 
      started either by Windows internally (often in TCP/IP scenarios) or by user 
      himself - those threads are not necessarily using libmysql.dll functionality, 
      but nonetheless the contribute to the count of open threads.
      
      2)process-initialization (DLL_PROCESS_ATTACH)
      my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
      Windows loader.
      
      
      Fix is to remove dll initialization code from libmysql.dll in general case. I
      still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
      will cause the old behavior (DLL init hooks will be called). This env.variable 
      exists only to prevent breakage of existing Windows-only applications that 
      don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
      discouraged and it will be removed in 6.0
[26 Aug 2008 2:05] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/52514

2666 Vladislav Vaintroub	2008-08-26 [merge]
      This patch fixes
      Bug#37226 Explicit call of my_thread_init() on Windows for every new thread.
      Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
      localsystem
      
            
      There are some problems using DllMain hook functions on Windows that 
      automatically do global and per-thread initialization for libmysqld.dll
            
      1)per-thread initialization(DLL_THREAD_ATTACH)
      MySQL internally counts number of active threads that and causes a delay in in 
      my_end() if not all threads are exited. But,there are threads that can be 
      started either by Windows internally (often in TCP/IP scenarios) or by user 
      himself - those threads are not necessarily using libmysql.dll functionality, 
      but nonetheless the contribute to the count of open threads.
            
      2)process-initialization (DLL_PROCESS_ATTACH)
      my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
      Windows loader.
            
      Fix is to remove dll initialization code from libmysql.dll in general case. I
      still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
      will cause the old behavior (DLL init hooks will be called). This env.variable 
      exists only to prevent breakage of existing Windows-only applications that 
      don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
      discouraged and it will be removed in 6.0
[1 Sep 2008 16:23] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/53011

2674 Vladislav Vaintroub	2008-09-01
      This patch fixes
      Bug#37226 Explicit call of my_thread_init() on Windows for every new thread.
      Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
      localsystem
        
      
      There are some problems using DllMain hook functions on Windows that 
      automatically do global and per-thread initialization for libmysqld.dll
      
      1)per-thread initialization(DLL_THREAD_ATTACH)
      MySQL internally counts number of active threads that and causes a delay in in 
      my_end() if not all threads are exited. But,there are threads that can be 
      started either by Windows internally (often in TCP/IP scenarios) or by user 
      himself - those threads are not necessarily using libmysql.dll functionality, 
      but nonetheless the contribute to the count of open threads.
      
      2)process-initialization (DLL_PROCESS_ATTACH)
      my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
      Windows loader.
      
      Fix is to remove dll initialization code from libmysql.dll in general case. I
      still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
      will cause the old behavior (DLL init hooks will be called). This env.variable 
      exists only to prevent breakage of existing Windows-only applications that 
      don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
      discouraged and it will be removed in 6.0
[1 Sep 2008 18:17] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/53018

2729 Vladislav Vaintroub	2008-09-01
      Bug#37226 Explicit call of my_thread_init() on Windows for every new thread.
      Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
      localsystem
        
      
      There are some problems using DllMain hook functions on Windows that 
      automatically do global and per-thread initialization for libmysqld.dll
      
      1)per-thread initialization(DLL_THREAD_ATTACH)
      MySQL internally counts number of active threads that and causes a delay in in 
      my_end() if not all threads are exited. But,there are threads that can be 
      started either by Windows internally (often in TCP/IP scenarios) or by user 
      himself - those threads are not necessarily using libmysql.dll functionality, 
      but nonetheless the contribute to the count of open threads.
      
      2)process-initialization (DLL_PROCESS_ATTACH)
      my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
      Windows loader.
      
      Fix is to remove dll initialization code from libmysql.dll in general case. I
      still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
      will cause the old behavior (DLL init hooks will be called). This env.variable 
      exists only to prevent breakage of existing Windows-only applications that 
      don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
      discouraged and it will be removed in 6.0
[1 Sep 2008 18:20] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/53019

2729 Vladislav Vaintroub	2008-09-01
      Bug#37226 Explicit call of my_thread_init() on Windows for every new thread.
      Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
      localsystem
        
      
      There are some problems using DllMain hook functions on Windows that 
      automatically do global and per-thread initialization for libmysqld.dll
      
      1)per-thread initialization(DLL_THREAD_ATTACH)
      MySQL internally counts number of active threads that and causes a delay in in 
      my_end() if not all threads are exited. But,there are threads that can be 
      started either by Windows internally (often in TCP/IP scenarios) or by user 
      himself - those threads are not necessarily using libmysql.dll functionality, 
      but nonetheless the contribute to the count of open threads.
      
      2)process-initialization (DLL_PROCESS_ATTACH)
      my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
      Windows loader.
      
      Fix is to remove dll initialization code from libmysql.dll in general case. I
      still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
      will cause the old behavior (DLL init hooks will be called). This env.variable 
      exists only to prevent breakage of existing Windows-only applications that 
      don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
      discouraged and it will be removed in 6.0
[1 Sep 2008 21:49] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/53026

2675 Vladislav Vaintroub	2008-09-01
      Bug#37226 Explicit call of my_thread_init() on Windows for every new thread.
      Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
      localsystem
        
      
      There are some problems using DllMain hook functions on Windows that 
      automatically do global and per-thread initialization for libmysqld.dll
      
      1)per-thread initialization(DLL_THREAD_ATTACH)
      MySQL internally counts number of active threads that and causes a delay in in 
      my_end() if not all threads are exited. But,there are threads that can be 
      started either by Windows internally (often in TCP/IP scenarios) or by user 
      himself - those threads are not necessarily using libmysql.dll functionality, 
      but nonetheless the contribute to the count of open threads.
      
      2)process-initialization (DLL_PROCESS_ATTACH)
      my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
      Windows loader.
      
      Fix is to remove dll initialization code from libmysql.dll in general case. I
      still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
      will cause the old behavior (DLL init hooks will be called). This env.variable 
      exists only to prevent breakage of existing Windows-only applications that 
      don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
      discouraged and it will be removed in 6.0
[1 Sep 2008 22:45] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/53031

2675 Vladislav Vaintroub	2008-09-01
      Bug#37226 Explicit call of my_thread_init() on Windows for every new thread.
      Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
      localsystem
        
      
      There are some problems using DllMain hook functions on Windows that 
      automatically do global and per-thread initialization for libmysqld.dll
      
      1)per-thread initialization(DLL_THREAD_ATTACH)
      MySQL internally counts number of active threads that and causes a delay in in 
      my_end() if not all threads are exited. But,there are threads that can be 
      started either by Windows internally (often in TCP/IP scenarios) or by user 
      himself - those threads are not necessarily using libmysql.dll functionality, 
      but nonetheless the contribute to the count of open threads.
      
      2)process-initialization (DLL_PROCESS_ATTACH)
      my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
      Windows loader.
      
      Fix is to remove dll initialization code from libmysql.dll in general case. I
      still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
      will cause the old behavior (DLL init hooks will be called). This env.variable 
      exists only to prevent breakage of existing Windows-only applications that 
      don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
      discouraged and it will be removed in 6.0
[13 Sep 2008 20:48] Bugs System
Pushed into 6.0.7-alpha  (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:hakan@mysql.com-20080725175322-8wgujj5xuzrjz3ke) (pib:3)
[15 Sep 2008 8:11] Bugs System
Pushed into 5.0.70  (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (pib:3)
[26 Sep 2008 12:30] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/54543

2698 He Zhenxing	2008-09-26 [merge]
      Merge 5.1 main -> 5.1-rpl
[29 Sep 2008 17:48] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/54682

2842 Vladislav Vaintroub	2008-09-29
      Bug#37226 -  Explicit call of my_thread_init() on Windows for every 
      new thread.
      Bug#33031 - app linked to libmysql.lib crash if run as service in 
      vista under localsystem.
      
      This patch completely removes DllMain() from the libmysql.dll in 6.0
      eliminating explicit my_thread_init()/WSAStartup() during dll load
      or thread attach. 
      
      This patch is slightly different from what is done in 5.0/5.1.
      The difference is that there is no way that to reactivate DllMain() 
      code (in 5.x it is possible  with LIBMYSQL_DLLINIT environment variable)
[29 Sep 2008 17:48] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/54683

2842 Vladislav Vaintroub	2008-09-29
      Bug#37226 -  Explicit call of my_thread_init() on Windows for every 
      new thread.
      Bug#33031 - app linked to libmysql.lib crash if run as service in 
      vista under localsystem.
      
      This patch completely removes DllMain() from the libmysql.dll in 6.0
      eliminating explicit my_thread_init()/WSAStartup() during dll load
      or thread attach. 
      
      This patch is slightly different from what is done in 5.0/5.1.
      The difference is that there is no way that to reactivate DllMain() 
      code (in 5.x it is possible  with LIBMYSQL_DLLINIT environment variable)
[1 Oct 2008 16:03] Bugs System
Pushed into 5.1.28  (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:vvaintroub@mysql.com-20080901215154-1reds0fnzqdvaqsm) (pib:4)
[23 Oct 2008 2:18] Paul DuBois
Noted in 5.0.70, 5.1.28, 6.0.7 changelogs.
[28 Oct 2008 21:03] Bugs System
Pushed into 5.1.29-ndb-6.2.17  (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:tomas.ulin@sun.com-20081028140209-u4emkk1xphi5tkfb) (pib:5)
[28 Oct 2008 22:22] Bugs System
Pushed into 5.1.29-ndb-6.3.19  (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:tomas.ulin@sun.com-20081028194045-0353yg8cvd2c7dd1) (pib:5)
[1 Nov 2008 9:48] Bugs System
Pushed into 5.1.29-ndb-6.4.0  (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:jonas@mysql.com-20081101082305-qx5a1bj0z7i8ueys) (pib:5)