I'm looking into making the switch from SourceSafe to SVN.

But, when I installed the 64-bit TortoiseSVN client version 1.5.5 on my Vista Ultimate x64 box, I got a BSOD upon the next reboot. The error was IRQL_NOT_LESS_OR_EQUAL.

I was able to boot by hitting F8 and going into the Last Known Good configuration. Once I got back to my desktop, I uninstalled the SVN client and rebooted again. This time, no crash. It was definitely the client, or something triggered by it.

I tried a re-install of the client, but this time with my antivirus disabled (Eset Nod32 64-bit) and everything else quit out of the notification area (ATI Catalyst stuff, SyncBack Pro, Daemon Tools, various Logitech stuff for my G15 and MX 1000, Window Clippings, HP Digital Imaging Monitor). The install went smoothly and I made it back into windows just fine, with the SVN client working, including shell integration.

My hunch is that some aggressive anti-virus protection was keeping the client from installing itself properly. Upon reboot, windows encountered some partially loaded software, couldn't make sense of it, and crashed. It's rare to see a BSOD that is not hardware or driver related, so I think some driver was getting confused somewhere.

2008-12-10 Update: Even after reinstalling Tortoise SVN with anti-virus disabled I was having BSODs on later reboots. I have now removed Eset Nod32 x64 Anti-virus, Daemon Tools, Adobe Version Cue Server, and Adobe Drive CS4 x64. Things seem to be working now. My new theory is that it was Adobe Drive CS4 x64. This app does version control and is a shell extension just like Tortoise SVN. I bet they were conflicting.

2008-12-10 Update 2: Successive reboots were OK, but when trying to run a disk check upon reboot, I was bluescreening. Thinking about this more carefully, I actually had it working earlier where it would boot up OK, but bluescreen during the disk check, if one was scheduled for the next bootup. I used SysInternals Autoruns app to search for stuff that is starting up with the system that may be conflicting. Doing a search for "Adobe" finds some stuff other than Adobe Reader / PDF-related stuff. Specifically I saw an Adobe Device Somethingerother (I should have written it down before deleting it, but I figured if I needed it back I'd reinstall CS4) and an Adobe File System driver. They both sound like they're related to the Versioning system or are otherwise related to hardware device management, which means they may mess with kernel-mode code, which can cause a BSOD. So, I removed both of those and I can now reboot and even run a disk check without problems. I THINK I've got it at this point but I'll let this configuration ride for a bit before I mark this as Solved.

2009-03-08 Update: No crashes in months, so this is a done deal! SOLVED!

The onboard Atheros LAN (never heard of them) on my P5Q Pro motherboard was freezing if I transferred large files (a few gigs) over the network. My Windows Server 2008 Server x64 driver was WHQL and current according to the ASUS support site. I went directly to Atheros and found a more recent driver that was also WHQL. I thought that would fix it but the problem persisted!

So I opened up my box-o-old-PCI-cards and I had an Intel Pro/1000 MT Desktop LAN adapter in there. After uninstalling the Atheros driver and disabling it in the BIOS, I installed the Intel card and its most recent driver.

Now the server is solid again, and can transfer large files with ease. I moved a 5 gig rar at over 80 meg/sec! So I don't know if my Atheros experience is common or I just got a bad board, but I'd rather just use an old, reliable part than RMA this motherboard. The Intel Pro/1000 series rocks (I have several of them, single and dual port varieties, PCI and PCI-X varieties).

So I upgraded a Virtual Machine Host to an ASUS P5Q Pro and 3Ghz Core 2 Duo. The installation went smoothly except for a couple things. One of them was that the Marvell BIOS would hang for over a minute with every bootup. This was pretty annoying but I eventually fixed it by changing the single optical drive that was on the IDE controller from Cable Select to Master. Now the BIOS takes only a couple seconds!

I think this behavior is by design, where Windows Vista and Windows Server 2008 treat networks they do not understand as public ones, assuming they are more dangerous. This poses a problem with VMWare Workstation 6.5 and VMWare Server 2.0, whose networks never register as anything other than Unidentified Networks, as far as I know.

So, if I'd like a computer running VMWare (a host) to be available for Network Discovery and / or File Sharing, I need to configure these options every time I boot up that computer, which is pretty annoying. Since I don't use the NAT or DHCP features of VMWare (I use only network bridging), I found a way to get rid of the Unidentified Network entirely by disabling the VMWare options I don't use. I can always enable them later.

1. Start the VMWare Network Editor as an Administrator
   
1. Hit the windows key and start typing "Network" without the quotes.
2. Right click "Virtual Network Editor" and select Run as Administrator.
2. On the NAT tab, set the VMnet host to Disabled and hit Apply. The Service Status should now read "Stopped". If you don't have an apply button it's because you didn't run the Virtual Network Editor as an Administrator.
   
3. On the DHCP tab, remove the two Virtual Networks called VMnet1 and VMnet8. Stop the DHCP Service, and hit Apply.
4. On the Host Virtual Adapters tab, remove VMnet1 and VMnet8 again, and hit Apply. This should cause the unidentified network to disappear from the Network and Sharing Center.

With no Unidentified Networks, your system should properly persist the Network Discovery and File Sharing options.

VMWare adapter bridging still works, and resources previously occupied by unused NAT and DHCP features are now freed up. If you ever need all this stuff back, just restore your original settings. I'd just use an unmodified VMWare host for reference.

2008/12/07 Update: I found an alternative work-around. You CAN change Vista and Server 2008's default behavior for Unidentified Networks. Just run the Local Security Policy. You'll see the setting under Network List Manager Policies. It's simply called "Unidentified Networks". Change the Location Type to Private and you're all set. You can leave User Permissions unset because the default setting will allow you to change the location. Immediately, and upon further reboots, your VMWare Unidentified Network will show up as Private, which will allow your Discoverability and File Sharing settings to survive system restarts.

Security Warning: By changing this setting, you're saying you trust unidentified networks to an extent. For example, if you were to install a device or application that created a network windows could not identify, it would immediately become private, and take on the private profile of your firewall, which is generally less restrictive. I personally find this risk acceptable, because I doubt I will be creating many unidentified networks.