StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2365891
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2010-03-02T19:05:01.217
FavoriteCount
0
LastActivityDate
2010-03-02T19:05:01.217
LastEditDate
LastEditorUserId
0
OwnerUserId
6970
ParentId
1057524
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
I suspect your problem was that somewhere deep within the called DLL, it made an outbound COM call to another apartment (another thread in the same process, or an object in the MTA, or another process entirely). COM permits an STA thread waiting for the result of an outbound call to receive another inbound call, processing it recursively. It's intended only for ongoing conversations between the same objects - i.e. A calls B, B calls A back, A calls B back again - but can receive calls from other objects if you've handed out an interface pointer to multiple clients, or the client has shared the interface pointer to another client. Generally it's a bad idea to hand out interface pointers to a single-threaded object to multiple client threads, as they'll only have to wait for each other. Create one worker object per thread. COM cannot suspend and resume execution at will on any thread - a new incoming call on an STA thread can only arrive through the message pump. When 'blocked' waiting for a response, the STA thread is actually pumping messages, checking with the Message Filter (see IMessageFilter) whether the message should be handled. However, message handlers must not make a new outgoing call - if they do COM will return an RPC_E_CANTCALLOUT_INEXTERNALCALL error ("It is illegal to call out while inside message filter.") Similar problems could occur if you have a message pump (GetMessage/DispatchMessage) anywhere within the native DLL. I've had problems with VB's DoEvents in interface procedures. CoInitializeEx should only be called by the creator of a thread, because only they know what their message pumping behaviour will be. It's likely that if you try to call it in DllMain it will simply fail, as your native DLL is being called in response to a COM call, so the caller must have ultimately already called CoInitializeEx on the thread in order to make the call. Doing it in the DLL_THREAD_ATTACH notification, for newly-created threads, might work superficially but cause the program to malfunction if COM blocks when it should pump and vice-versa.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POLegacy VB6 COM+ DLL calling into native Win32 DLL -- threading issues with STA?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USMike Dimmick
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.