Soon after the kernel comes up, the chromeos_startup script uses the ply-image command to display a static splash image onscreen.  If your system didn't get to this point, it probably means that the kernel failed to boot (although it may be the case that some virtual machines are also unable to display the splash image).

Hopefully not too long after that, the ui upstart task starts the X server.  The X server makes a copy of the framebuffer's contents at startup, so the same splash image should still be onscreen after it has started, but you'll also see an arrow pointer appear.  If you never see the arrow, it means that X failed to start.  You may be able to find out why by checking /var/log/ui/ui.LATEST (stderr from processes started by the UI task) or /var/log/Xorg.0.log.  If X is running, you should be able to see the process using the ps command and it should be listening on a socket at /tmp/.X11-unix/X0.

After X is running, the UI task starts session_manager, which starts Chrome and chromeos-wm (the window manager) simultaneously.  You can check /var/log/session_manager to see if the session manager is having trouble starting the two processes; if either of them exits unexpectedly, it'll also be logged there.

Once Chrome has started successfully, it creates a few windows.  Most noticeably, it creates a new background with some information (time, battery, network, etc.) in its upper right corner.  If this window never appears, it probably means that Chrome didn't start successfully.  You can check if this is the problem by looking at the session manager log, Chrome's log at /var/log/chrome/chrome, and the UI task's log (output from some parts of Chrome, most notably libcros, sometimes end up here, although they probably shouldn't).

If the window manager fails to start, you'll probably still see Chrome's login windows onscreen, but they'll be jumbled all over the place instead of arranged correctly.  The window manager's output before the user has logged in is spread between the UI task's log (before it knows whether the user is logged in or not) and /var/log/window_manager/chromeos-wm.LATEST (after it knows that the user 

isn't logged in).

After the user types their password and hits enter, Chrome displays a spinner on top of the user entry.  If the password was correct, Chrome unmaps the login windows and gets to work setting things up for the user's session.  The window manager continues displaying the login windows onscreen until Chrome has mapped the first browser window.  If the system appears to be stuck in this state for a long time, it probably means that Chrome is crashing; see the information about Chrome in the next section.

Once the user has logged in, Chrome and the window manager switch to new log files located within the user's encrypted home directory: Chrome starts writing to /home/chronos/user/chrome and the window manager uses /home/chronos/user/log/chromeos-wm.LATEST.

If Chrome or the window manager crash, the session manager will notice and try to restart them.  Depending on the nature of the crash, the processes may write a helpful message to their log files before getting restarted (which will cause them to start new log files; you should able to find the older versions alongside the new ones).  Crash dumps may also be written to /home/chronos/user/crash.  Both Chrome and window manager crashes will result in the screen flickering, but if Chrome crashes, you'll also lose all of your tabs and get a "Chrome didn't shut down correctly" infobar when it restarts. If the window manager crashes, you should keep your tabs and windows, although the focus may get moved to a different window.  The session manager will restart Chrome a limited number of times; if it's crashing repeatedly after it's restarted, you'll soon get sent back to the login screen.

X can also die.  If this happens, you'll get booted back to the login prompt as well, and there should be a message about the crash in /var/log/Xorg.0.log.