3

I have a DLL (written in C) that uses static thread local storage (__declspec(thread)), and I want to use this DLL from a Visual Basic graphic interface.

Unfortunately, when running the interface on Windows XP that DLL which use static thread local storage crashes when it try to acess its thread variables.

How can I solve this problem?

Thanks, Regards

G.B.

PS I would like to not modify the DLL.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Beppe
  • 381
  • 2
  • 7
  • 15
  • please show us the VB code you use. – Bernd Elkemann Mar 04 '11 at 13:53
  • 1
    Is this by chance anything like [Consequences of using variables declared __declspec(thread) ](http://blogs.msdn.com/b/oldnewthing/archive/2010/11/22/10094489.aspx) from The Old New Thing? – user Mar 04 '11 at 13:54
  • @Michael Kjörling Yes, I found a similar problem there, but it was solved for a c# application. – Beppe Mar 04 '11 at 14:30
  • You are supposed to ask one question at a time. I believe I have already answered your original question. You should ask a new question. – David Heffernan Mar 04 '11 at 15:06
  • For the benefit of SO users, here is a brief description of [the solution posted by "Shf"](http://blogs.msdn.com/b/oldnewthing/archive/2010/11/22/10094489.aspx#10095505) on The Old New Things, with endorsement from Raymond Chen. A "new main executable" will be created in C++/CLI; this "new main executable" will statically link to the problematic DLL written in C/C++ which had used TLS; and this "new main" will also load the original .NET main executable (as if it was a regular .NET assembly) and directly call into its `Program.Main()`. See link for full description. – rwong Jan 16 '15 at 14:46

1 Answers1

5

This is a known limitation of static TLS. Although you aren't explicitly calling LoadLibrary(), the VB runtime does so on your behalf.

Note that this limitation has been lifted from Vista. The most comprehensive reference that I know of is on Ken Johnson's blog.

You may be able to get around the problem if you could get the DLL included in the imports table of the generated .exe, which would likely involve some PE hacking and I'm far from certain it's a viable strategy. Otherwise you'll need to change the DLL.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Hi David, thanks for the answer, in the article you posted, it said that the error happens only when the DLL is dynamically loaded, so if I load the DLL in a static way the problem should be fixed. How to do it? Thanks – Beppe Mar 04 '11 at 14:18
  • 1
    @Beppe I'm not even sure you can arrange for the DLL to be implicitly loaded with VB6. I think your only hope would be to modify your .exe's import table to include a reference to your DLL. The assumption of early implementations of implicit TLS is that the DLL is loaded implicitly. – David Heffernan Mar 04 '11 at 14:23
  • I am trying to access Ken Johnson's blog on TLS which is mentioned in several places however the link does not seem to work. any idea if it is taken down or moved? Is there a back up in the Way Back Machine or some place else? – Richard Chambers Feb 21 '16 at 06:07
  • @DavidHeffernan Your first link is dead. – Bram Jun 08 '20 at 03:55