Why does the VB.net compiler crash after I move a project?

Question

I'm migrating data from an old laptop to a new laptop, including some vb.net projects in visual studio 2008. But when I try to open some of them on the new laptop, I quickly get a dialog stating that the vb compiler has crashed and asking me if I want to close, debug, or check online for solutions. Visual studio then, frustratingly, closes.

The projects don't crash when opened on the old laptop, and other migrated projects open without crashing. So it must be some property of the projects that becomes corrupted by moving them.

I've done searches and found posts by people with similar-sounding problems, but no answers. Why is this happening, and how do I fix it?

Error Details:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: devenv.exe
  Application Version:  9.0.21022.8
  Application Timestamp:    47317b3d
  Fault Module Name:    kernel32.dll
  Fault Module Version: 6.0.6001.18215
  Fault Module Timestamp:   4995344f
  Exception Code:   e06d7363
  Exception Offset: 0002f328
  OS Version:   6.0.6001.2.1.0.768.3
  Locale ID:    4105

Additional information about the problem:
  LCID: 1033

Read our privacy statement:
  http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409

The old laptop is windows xp and uses visual studio professional. The new laptop is windows vista and uses visual studio team. The 'migration' was a straight copy paste of the source files.

Answer 1

The project file may be referencing a location that no longer exists (i.e. it was on the old laptop and not on the new one). For example, are the drives different (D: on one and C: on the other)?

Answer 2

The project crashes because anything equivalent to the following snippet of code crashes VS2008, but not VS2008 SP1:

Public Class B(Of T)
    Protected Function P(ByVal arg As T) As Boolean
    End Function
End Class
Public Class C
    Inherits B(Of Integer)
    Private Sub New(ByVal arg As Integer)
        Dim d = Function() P(arg)
    End Sub
End Class

Notes:

• Upgrading to SP1 fixes the problem.
• There's nothing special about 'Boolean' or 'Integer', they were just convenient types
• Combining both subs into a single class makes the bug disappear.
• Using a non-generic argument in the base class function makes the bug disappear.
• Using a non-constructor sub in the child class makes the bug disappear.
• A naive C# translation of the bug doesn't cause the C# compiler to crash.

I can finally blame it on the compiler. Not my fault!