none
CreateThread return GetLastError 8 RRS feed

  • Question

  • Application loads dll. Inside DllMain there is a code:

    HANDLE ht = CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)Main, NULL, 0, &tid);

    hThread is NULL and GetLastError return 8.

    Friday, July 5, 2013 10:46 AM

Answers

  • At all you should not add API calls into DLLmain, see this blog here:

    http://blogs.msdn.com/b/oldnewthing/archive/2004/01/27/63401.aspx

    The functionality should be in an exported DLL function.


    Best regards

    Bordon

    Note: Posted code pieces may not have a good programming style and may not perfect. It is also possible that they do not work in all situations. Code pieces are only indended to explain something particualar.

    Friday, July 5, 2013 11:14 AM
  • DllMain best practices...

    http://msdn.microsoft.com/en-us/library/windows/hardware/gg487379.aspx

    Relevant part...

    You should never perform the following tasks from within DllMain:

    • Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.
    • Synchronize with other threads. This can cause a deadlock.
    • Acquire a synchronization object that is owned by code that is waiting to acquire the loader lock. This can cause a deadlock.
    • Initialize COM threads by using CoInitializeEx. Under certain conditions, this function can call LoadLibraryEx.
    • Call the registry functions. These functions are implemented in Advapi32.dll. If Advapi32.dll is not initialized before your DLL, the DLL can access uninitialized memory and cause the process to crash.
    • Call CreateProcess. Creating a process can load another DLL.
    • Call ExitThread. Exiting a thread during DLL detach can cause the loader lock to be acquired again, causing a deadlock or a crash.
    • Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky.
    • Create a named pipe or other named object (Windows 2000 only). In Windows 2000, named objects are provided by the Terminal Services DLL. If this DLL is not initialized, calls to the DLL can cause the process to crash.
    • Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash.
    • Call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
    • Use managed code.

    Blog: http://ntcoder.com/bab


    Posts are provided as is without warranties or guaranties.



    Friday, July 5, 2013 12:01 PM
    Moderator
  • Hi Terminus Amulius,
     

    The reason for the restriction in calling certain function from dllmain
    is that while DllMain is called the loader-lock is held.Therefore DllMain
    is designed to perform minimal initialization tasks.You cannot call any function in DllMain
    that directly or indirectly tries to acquire the loader -lock.
    Otherwise you may experience dead lock or crash.



    See the best practices doc in MSDN and you can see few operations are safe within dllmain.
    You can call some of the win32 functions(kernel32.dll) that are not listed in the restricted API.
     
    Better you to avoid operation from DllMain as it is called from the loader.
     
    thanks,
    Bhash
    Friday, July 5, 2013 1:45 PM

All replies

  • At all you should not add API calls into DLLmain, see this blog here:

    http://blogs.msdn.com/b/oldnewthing/archive/2004/01/27/63401.aspx

    The functionality should be in an exported DLL function.


    Best regards

    Bordon

    Note: Posted code pieces may not have a good programming style and may not perfect. It is also possible that they do not work in all situations. Code pieces are only indended to explain something particualar.

    Friday, July 5, 2013 11:14 AM
  • DllMain best practices...

    http://msdn.microsoft.com/en-us/library/windows/hardware/gg487379.aspx

    Relevant part...

    You should never perform the following tasks from within DllMain:

    • Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.
    • Synchronize with other threads. This can cause a deadlock.
    • Acquire a synchronization object that is owned by code that is waiting to acquire the loader lock. This can cause a deadlock.
    • Initialize COM threads by using CoInitializeEx. Under certain conditions, this function can call LoadLibraryEx.
    • Call the registry functions. These functions are implemented in Advapi32.dll. If Advapi32.dll is not initialized before your DLL, the DLL can access uninitialized memory and cause the process to crash.
    • Call CreateProcess. Creating a process can load another DLL.
    • Call ExitThread. Exiting a thread during DLL detach can cause the loader lock to be acquired again, causing a deadlock or a crash.
    • Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky.
    • Create a named pipe or other named object (Windows 2000 only). In Windows 2000, named objects are provided by the Terminal Services DLL. If this DLL is not initialized, calls to the DLL can cause the process to crash.
    • Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash.
    • Call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
    • Use managed code.

    Blog: http://ntcoder.com/bab


    Posts are provided as is without warranties or guaranties.



    Friday, July 5, 2013 12:01 PM
    Moderator
  • Hi Terminus Amulius,
     

    The reason for the restriction in calling certain function from dllmain
    is that while DllMain is called the loader-lock is held.Therefore DllMain
    is designed to perform minimal initialization tasks.You cannot call any function in DllMain
    that directly or indirectly tries to acquire the loader -lock.
    Otherwise you may experience dead lock or crash.



    See the best practices doc in MSDN and you can see few operations are safe within dllmain.
    You can call some of the win32 functions(kernel32.dll) that are not listed in the restricted API.
     
    Better you to avoid operation from DllMain as it is called from the loader.
     
    thanks,
    Bhash
    Friday, July 5, 2013 1:45 PM