¿Y cuál es la duda en concreto? Porque yo no he visto que hayas preguntado nada. Solamente, has puesto código, y lo has puesto mal.

Un saludo.

Si es una necesidad del tipo "hasta que..." en vez de "mientras que...", entonces puedes hacer el código algo más comprensible de la siguiente manera:

Do Until MyWorker.CancellationPending
    ...
Loop

---

Para hacer una pausa (o dicho de otra forma: bloquear la ejecución del hilo actual) durante un intervalo definido (ej. 5 segundos) debes utilizar el método System.Threading.Thread.Sleep():

Sleep(TimeSpan.FromSeconds(5))
CheckProcess()

El uso que le doy a la class ManualResetEvent es para implementar una funcionalidad de pausar/continuar a demanda o petición del usuario, puesto que el método ManualResetEvent.WaitOne() sirve para bloquear la ejecución del thread durante un tiempo indefinido hasta que se reciba una señal llamando a ManualResetEvent.Set(), por eso si te fijas en mi ejemplo uso la constante de tiempo infinito System.Threading.Timeout.Infinite.

Si tu especificas 5000 ms en el parámetro del método ManualResetEvent.WaitOne(), con eso le estás diciendo que el hilo debe esperar hasta que transcurra ese intervalo de tiempo definido o hasta recibir una señal durante ese tiempo, y si no recibe una señal durante ese tiempo se resumirá el hilo, esto quiere decir que le estás dando la misma funcionalidad que si utilizases el método System.Threading.Thread.Sleep(), pero no debes hacerlo, primeramente por que es innecesario, segundo por que es de buena costumbre utilizar el método más apropiado para "X" finalidad y en este caso el método System.Threading.Thread.Sleep() es el que ha sido diseñado para dicha finalidad, y tercero por que podría ocasionarte un comportamiento indebido por culpa de un fallo de lógica humana, por ejemplo si enviases una señal en otra parte del código durante ese intervalo de tiempo.

---

Depende del propósito del código, pero ya estás corriendo la tarea de la "verificación de procesos" en un hilo secundario ...puedes llevar a cabo la "verificación de módulos" de forma sincrónica si eso no te suponiese inconvenientes.

Saludos!

No se si he llegado a entender bien lo que quieres conseguir, pero si tienes un TextBox que muestra unos datos los cuales luego necesitas leer desde otra class, entonces puedes seguir haciendo eso.

Si necesitases evitar conflictos entre threads entonces también podrías declarar una variable compartida y asignarle el valor cada vez que se modifica el texto del TextBox:

Class Class1
    Friend Shared Username As String
 
    Friend TextBox1_TextChanged(sender As Object, e As Eventargs) Handles TextBox1.TextChanged
        Class1.Username = DirectCast(sender, TextBox).Text
    End Sub
End Class1

Class Class2
    ...
    MsgBox(Class1.Usrname)
    ...
End Class2

Si necesitases leer múltiples objetos/valores desde la otra class, entonces definir un tipo personalizado para almacenar esos datos como tu dijiste sería ideal. También podrías serializar el tipo/clase en un archivo local.

Saludos

Los errores se controlan con bloques try/catch:

Declaración de objetos...
 
Try
    Instanciación de objetos...
    Sentencias de procesos/modulos...
 
Catch ex As (Tipo De Excepción) ' When (Condición)
    Informar de ex.Message
 
Finally
    Liberación de objetos declarados.
 
End Try

( el bloque Finally es opcional en caso de que no uses objetos "disposables" )

Ahora, suponiendo que hayas declarado un evento en tu código entonces por supuesto puedes disparar ese evento con RaiseEvent cuando controles un error  ...pero yo diría que no es lo que realmente preguntas.

Saludos