This problem is driving me nuts so if anyone can help resolve it i would really appreciate it. It is a unique situation in dealing with different user accounts.

I have a win32 project in vs 2005

I create a thread that calls a dialogbox from resource when an event happens.

void Thread{
 if event() {
  DialogBox(hinst, MAKEINTRESOURCE(DLG_DELETEITEM), hwnd, DlgFunc)
 }
}

It works just fine initially.

I then switch user accounts on windows xp/vista (not logging out) and log into a second account and create a second instance of the same application....which is creating another instance of the thread

However, if I switch back to first account from second account (again not logging out), the dialogbox is not shown in the currently open windows account when the event happens. It however pops up on the SECOND account.

Anyone have any ideas? It seems the thread is not exclusive to each account and only has a handle to the resource most recently created.

thanks in advance

Recommended Answers

All 5 Replies

I know this isn't very helpful but that isn't a threading issue. I've seen it before having dialogs come up in different user accounts - damned if I can remember how I fixed it - but at least you can eliminate concurrency from the list of possible causes.

What is the event() you are waiting for?
Presumably this event is being seen by both processes.
If you are talking about a windows synchronisation event, these can be accessed by more than one process (depending on the creation method).

I know this isn't very helpful but that isn't a threading issue. I've seen it before having dialogs come up in different user accounts - damned if I can remember how I fixed it - but at least you can eliminate concurrency from the list of possible causes.

Stinomus , thanks for the input. I will investigate other possible reasons for this. However, if you can somehow remember how you fixed it that would be awesome!

What is the event() you are waiting for?

The event is waiting for a handle to an object which is triggered at the driver level using the WaitForSingleObject() function.

The event is waiting for a handle to an object which is triggered at the driver level using the WaitForSingleObject() function.

So you are presumably getting a handle to an existing named event by using CreateEvent() or similar?
I also presume that the driver level event is first created in a third (driver) process and is visible to other processes.
If that is the case, each of your processes running under different users will be waiting on the same object and either one of them could be triggered. Seems reasonable to me. Why do you think it should only be the one you are actually observing?

Ok thanks for everyone's advice.

I fixed the problem.

The event that i was listening for was being seen across both user accounts since it was at the driver level.

Therefore, each instance of the application that was created in each user account created a new thread which created a new handle to the event. This caused the thread in the other accounts to lose their handles.

That's why when i switched back to the first account, the thread had lost its handle and could not call up the dialog box. Furthermore, the thread in the second account was still listening for the event to be triggered which caused the dialogbox to come up in the second account.

This was all fixed by making the threads either sleep or resume when switching accounts and also reclaiming the handles to the event once a user session was opened back up.

Hope this helps anyone else that runs into this problem.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.