I know .Net and C# pretty well, but never even looked at VB.
My problem is: our Win32 COM library is used by a number of clients, and we see that the number of failures is higher for those who use the library from VB (both VB and VB.NET) than for those who use C++, C# or Delphi. One thing about our library is that it is supposed to be used from one thread only - can some threading magic by VB be the cause of failures?
Clients tell us the do not create any extra threads on their own.
VB.NET = C# with a little different syntax. Seriously, you can translate VB.NET into C# line-for-line 99% of the time. Neither language creates threads under your nose without you knowing about it.
At most, if your clients are using VB.NET with Option Strict Off, then VB.NET's late-binding can cause more problems than it fixes -- its hard to know for sure without seeing the actual exceptions you're clients are reporting. In any case, chalk your clients failures up to less skillful programmers and bugs in their own library, not to your code or Microsofts implementation of VB.NET.
One case is Finalize methods. The CLR calls them from background thread(s) associated with the garbage collector part of the system. Most likely, your users should just not be calling your component from within Finalize.
Also watch for the BackgroundWorker or delegate BeginInvoke. Although the user does not create "any extra threads on their own", these mechanisms executes code on a thread pool thread separate from the main GUI thread.
By magic, no. VB.Net will not do any extra threading under the hood. In this respect it's the same as C#.
VB6 and earlier can impact threading because all of it's objects will be STA COM objects. This won't add any threads to your program, but merely restrict the manner in which the VB6 objects can be accessed.