>>>>>>>>>Hi all,
>>>>>>>>>
>>>>>>>>>Has anyone run into any issues running a WPF multi threaded application on a VM? We have an application that is in QA cycle now and one of the testers is having some issues at startup where the startup code is in a background thread. I found some references on the web regarding some known issues surrounding VM's but not real specific. We cannot duplicate this on a non-VM.
>>>>>>>>>
>>>>>>>>>Just curious if anyone has any discoveries or information about this.
>>>>>>>>
>>>>>>>>Can you be more specific about the problems being experienced?
>>>>>>>>Are you using BackgroundWorker or managing your own threads?
>>>>>>>>At a guess the most likely problems will be if the thread attempts to interact with the UI and you use the wrong DispatcherObject...
>>>>>>>>UPDATE: Oh, and VM - Virtual Machine or ViewModel :-}
>>>>>>>
>>>>>>>I am using a BackgroundWorker in part because it handles the interaction better to the UI thread. I am raising an event within the Worker_ProgressChanged event of the Background worker to raise an event on the application of when it is at specific stages. This does not seem to be happening in as the stage does not get notified. What I have discovered however, is I can now duplicate this on my machine if I run the exe from the directory directly. It does not happen if I run the application from within VS either in debug mode or in release mode.
>>>>>>>
>>>>>>>What would be different specifically if running the exe or running within VS in release mode? I can post some code if it helps to understand what is happening.
>>>>>>
>>>>>>Code would be good (especially if it is repro code :-} )
>>>>>>I must admit I've not come across anything the implies behaviour will differ between running from the IDE and an EXE directly but I suppose it's not impossible.....
>>>>>
>>>>>I have added some logging in more places to try to narrow this down. I suspect it is a timing issue between running in the IDE and the EXE as I can't think of why it would be different eitherwise. Of course with threading using breakpoints to find timing issues is useless and logging changes the timing also. Since the background thread changes its status a few times and that triggers different things I am looking at if the status could change through a critical step fast enough to cause a problem. It appears thus far the events are firing and the status is changing, but some code depends on a specific status and that may not be there long enough to actually happen. My bad if this is the case.
>>>>>
>>>>>Basically this is a setup and login process to a web service. I have a status after some setup work to notify the application a login is now possible if the user happened to type the login credentials and click the login button. At that point the login would continue as opposed to waiting. The next status of the background worker would be completed, and I am wondering if I am not catching this condition where the status changed to completed inbetween the time the login was requested and the status changed to LoginReady then to Completed.
>>>>
>>>>I'm assuming your storing the current progress and relying on that to determine what to do in the main thread? Assuming your userstate is a string then something like

 string currentState;
>>>>        void bg_ProgressChanged(object sender, ProgressChangedEventArgs e)
>>>>        {
>>>>            currentState = (string) e.UserState;
>>>>        }

If you are concerned that currentState will update again before being acted on you could set a flag when the right state is reached and rely on that instead?

bool OKToDoSomething;
>>>>        string currentState;
>>>>        void bg_ProgressChanged(object sender, ProgressChangedEventArgs e)
>>>>        {
>>>>            currentState = (string) e.UserState;
>>>>            if (currentState == "OKToDoSomething") OKToDoSomething = true;
>>>>        }

>>>>
>>>>
>>>>>I think this is probably a code thing.
>>>>>Timothy
>>>
>>>Well, I don't understand why, but I have found the issue and put a work around. I have a while loop that executes within the worker thread. This loop is basically waiting for a property to change that represents the status of the other thread. The property definately is updated to "LoginReady" but the while loop never discovers this. This is only when executing outside VS. If I run within VS it works fine. I added a logging in the loop and it started working so slowing it down just slightly to write to the log was all it took. I have added the thread sleep for a half second and now it works running the exe. Go figure. And why would the while loop not notice the property is not set to "LoginReady"?
>>>
>>>

>>>/// <summary>
>>>/// Authentication Worker DoWork Event Handler
>>>/// </summary>
>>>private void AuthenticationWorker_DoWork(object sender, DoWorkEventArgs e)
>>>{
>>>    // The Sender is the BackgroundWorker object
>>>    // we need for checking cancellation.
>>>    var worker = sender as BackgroundWorker;
>>>
>>>     // Need to make sure and wait until the BackgroundWorkerStatus is LoginReady.
>>>     while (StartupWorkerStatus != BackgroundWorkerStatus.LoginReady)
>>>     {
>>>           // Added this sleep to allow the while loop to breath while running the exe
>>>           System.Threading.Thread.Sleep(500);
>>>            if (StartupWorkerStatus == BackgroundWorkerStatus.Failed ||
>>>                StartupWorkerStatus == BackgroundWorkerStatus.Cancelled)
>>>            {
>>>	AppLog.Add("Authentication Background Worker is unable to start because the Startup Worker " + enum.GetName(typeof(BackgroundWorkerStatus), StartupWorkerStatus));
>>>	return;
>>>             }
>>>        }
>>>
>>>       // Updates Background Worker Status to RunningLogin
>>>       worker.ReportProgress(4);
>>>			
>>>        // Perform the login
>>>        Communicator.DoLogin();
>>>
>>>        // more work code ommitted ......
>>>

>>
>>I wouldn't use a while loop for this. It can get optimized out of existence.
>
>Don't see how that one could be optimized out :-}
>
>
>>See: Do We Really Need Locks and Barriers? Here:
>>
>>http://www.albahari.com/threading/part4.aspx
>>
>>When one thread needs to wait for another thread you are better off using an AutoResetEvent or a Semaphore.
>
>Great link!
> I agree that AutoResetEvent would be good here. Or maybe just Monitor Wait/Pulse ?

The last time I did something similar, I ended up using a ManualResetEvent.

I don't think I would use Monitor for this, but then I can't see all your code.