Random Stuff

I use hibernate when I am done using my Windows Vista x64 machine for the day. Usually I would use sleep but for some reason my DFI motherboard doesn’t work with Vista’s sleep feature. Hibernate usually works fine, but maybe once or twice a month the computer will crash with a bluescreen when entering hibernation. Bluescreen errors are really annoying because Windows doesn’t give the user any useful information as to what is causing the error so it is really hard to fix it.

After some trial and error I’ve figured out how to gain some information on figuring out what is causing the bluescreen. The following steps show you how to determine which binary is causing the error. These steps should work on Windows XP, Vista, and Windows Server:

1. Go here to download and install the 32 or 64 bit version of the Debugging Tools for Windows: http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx.
2. Wait until your computer bluescreens.
3. Once the computer reboots open a cmd.exe window. On Vista you must use an elevated permissions window.
4. Type this command at the prompt to allow debugging symbols to be found:  set _NT_SYMBOL_PATH=symsrv*symsrv.dll*f:\localsymbols*http://msdl.microsoft.com/download/symbols
5. Go to the location that you installed the debugging tools and type “windbg.exe”.
6. Select File –> Open Crash Dump.
7. Select c:\Windows\MEMORY.DMP.
8. Type in the windbg window:   !analyze -v
9. Windbg will show you information about the crash. I look at IMAGE_NAME to determine what binary is causing the problem.

Usually I will see a binary that starts with “nv” which means nVidia. My graphics card drivers are usually the ones that are causing the problem. If you don’t recognize the binary then try searching for it online and you’ll probably be able to figure out what it is.

If you can figure out what it is then you can try installing a newer version of the program or driver to see if that helps.

Update: I have confirmed that Rizal’s suggestion in the comments fixes the problem. Add a “--no-sandbox” argument to the Chrome shortcut and Chrome should start working. To do this right click on the Chrome desktop icon. In the Target box add “--no-sandbox” without the quotes to the very end of the box.

Update2: Chrome’s sandbox is an additional security feature that restricts each browser process from accessing anything on the system that it is running on. So disabling it is usually not a good idea. But in this case the browser is so new that people are mostly using it as a test and to verify website compatibility so I think most people are ok with disabling it. As far as I know using the “no sandbox” argument is no worse than browsing with the current version of Firefox or Internet Explorer. Google or Symantec will fix the problem in a future release and you can re-enable the sandbox at that time.

Original post:

I installed the new Google’s new Chrome browser within minutes of being released. It installed ok but it wouldn’t run at all. As soon as it started up I would get this error:

The application failed to initialize properly (0xc0000005). Click ok to terminate the application.

This appears to be caused by Symantec Endpoint Protection (SEP). Unfortunately I am running this on a corporate machine and there is no way for me to disable or configure the Symantec software.

Uninstalling SEP is always an option to get Chrome to work. Another less drastic method that was posted online:

I was able to go into SEP - Change Settings - Centralized Exceptions,
click Configure Settings, and add c:\documents and settings\<username>
\Local Settings\Application Data\Google\Chrome\Application\chrome.exe
to the list. However I had to reboot the machine to be able to open up chrome w/out the error message.

For more information read this thread: http://groups.google.com/group/google-chrome-help-troubleshooting/browse_thread/thread/41ef35857180e154/.

Recently I tried setting up Exact Audio Copy (EAC) in Vista Ultimate x64. With disk space being so cheap nowadays I also wanted to use WMA Lossless encoding. With lossless encoding no audio fidelity is lost and I can always convert back to the original WAV files if I want to in the future.

The first thing I did was go to the Windows Media Encoder website so that I could download the encoder. Since I’m running Vista x64 I grabbed the x64 version of the encoder. Unfortunetly this is a bad idea. What they don’t say on the site is that if you use the 64 bit encoder then all your other software must also be 64bit.  Since EAC is only 32 bit I never was able to get it to work with the x64 encoder.

Finally I gave up, uninstalled the 64bit encoder and reinstalled the 32bit encoder. After I did that EAC worked fine. The Configuration Wizard in EAC detected and set up the encoder perfectly.

The annoying thing about EAC is that when using an external encoder it pops up a new command window after every track is extracted. This makes the computer practically unusable because new windows keep popping up all the time. I looked around and found under File –> EAC Options –> Tools there is an option called “Do not open external compressor window”. This sounded like exactly what I needed so I checked it. Unfortunately this completely broke the external compression. The resulting WMA files would be corrupted after being encoded. I’m not sure if this option works on other OSes, but if you are using Vista x64 don’t select it!

Here is the solution I found to the popup window problem:

1. Hit Ctrl-Q to bring up the Compression Queue Control Center.
2. Check the “Make all compression tasks sleep” option.
3. Close the dialog.
4. Hit F9, then go to the Tools tab.
5. Check the “On extraction, start external compressors queued in the background” option.
6. Optional: Set the number of simultaneous external threads equal to the number of CPUs that you have.

Now when you extract a CD all of the tracks will go into the compression queue. When you are done extracting all your CDs, go back to the Compression Queue Control Center and uncheck the sleep option. This will make all encoding tasks start (then go eat dinner or something else that takes a while).