cb-seamonkey-win32-02 has some not yet clearly defined problem, it auto-starts buildbot in a way that I can't see the processes running as seabld even when I log in as seabld, and auto-starts once again when I log is a seabld I get another buildbot running. I suspect that the systematic reftest and mochitest-plain failures we're seeing are connected to this. The strange thing is that -win32-01 should be set up identically but is working correctly.

I now killed all seabld processes from an Administrator login and then logged in as seabld, which autostarted buildbot again. Let's see if that makes a difference.

OK, unittests seem to run OK from the buildslave started with the regular login. I still need to find out what causes the autologin to end up botched in a way that it creates those errors. For now, the machine should work fine until it gets rebooted (which could happen tomorrow when the Parallels issue is being debugged).

This happens consistently on both VMs now when they start the autologin after a reboot. logon.src (the login screen saver!) is running in parallel to the python process, it somehow looks like seabld would never fully log on but already start buildbot from the Startup menu. Again, when I log in as Administrator, kill those processes, and log in as seabld (all from RDP), everything works fine. Ben, have you guys seen things like that on Windows VMs?

NOT major because it's no production setup yet and we have a well-working workaround for now.

(In reply to comment #4) > NOT major because it's no production setup yet and we have a well-working > workaround for now. Well, I'd say _major_ precisely because it prevents from switching this (newer) setup to production :-| (Though I agree our current (older) production setup is still running (fine enough).)

cb-seamonkey-win32-02 misbehaves currently: can you fix it?

(In reply to comment #6) > cb-seamonkey-win32-02 misbehaves currently: can you fix it? Done, should be OK again. I still need to find out what we are doing differently than on Firefox machines that could cause this, but for the moment, we look fine again.

Fixed by bug 571855.