Are you really using threads? Everything you have shown or talked about are UI components running on the UI thread. Also, if you are really using threads, then there would be no reason to stop one to allow the others to run unless the one thread is holding a lock on a critical section, which would be a bad design to start with. Threads run simultaneously and independently unless they use shared resources or code, all of which should be locked and released as quickly as possible, and DoEvents will have nothing to do with that in any way. Nothing you have said suggests that you are really using multiple threads, and you appear to believe that DoEvents will solve the problem, which means that they aren't multiple threads at all, but just different chunks of code in the UI thread running sequentially.

The bottom line is this: If the solution requires DoEvents, then the solution could be improved. If the solution requires thread.sleep, and the solution doesn't use threading, then the solution is wrong.

How to fix either one is not so simple, though, especially once you have gone a ways down either road. We all think by forming mental models of how a process works. As long as we think we are making progress towards our goal, we feel that the mental model is correct. When we hit an obstacle, the first thought is not to throw out the mental model, but to try to solve the problem within the model. Anything else would be something close to madness. Unfortunately, this means of operating can cause us trouble when we get into a blind alley, because we will first attempt to push through the obstacles before us before we realize the route will lead us nowhere. You are in such an alley right now. The problem is that realizing that your mental model of the problem is flawed is no more than a first step, and a highly unsatisfying step, at that. The next step is to come up with a different mental model, and that isn't easy. Still, it is what you have to do.

The new model has to have these features:

1) No use of DoEvents. I'm not totally opposed to DoEvents as some folks are, but in this case you would be better off assuming that it didn't exist, since it is acting as a mental trap.

2) No spin waiting. This is true in all cases in VB.NET. There is a rare situation where spin wating is ok, but that is in pretty low level thread pool managment code. For everyone else, if you are writing a loop where you just loop waiting for some external event (not in the loop itself) to occur, then you are spin waiting (also called busy waiting), and that's really bad, especially in this modern, mobile, age.

With those constraints, you have to be willing to start processes off, such as the navigation, and move any other code to some event triggered by the process. If the process can be started off in different ways, or by different initiators, such as two different means of navigating, and if you don't want the process to be handled the same way in all cases, then you have to add some code so that when the event occurs, the event handler knows in which way it has to act. This can be done with global variables, form level variables, or it could even be done by adding something to the .Tag property of a control (I'm not sure whether the WebBrowser even HAS a .Tag property, but it might).