IIS Express Worker在运行测试时已停止工作

Question

I have integration tests that are running against a spun-up IIS Express server. On my other team member's machines, these tests run fine. However, on my machine, IIS Express crashes midway through the test run, causing all tests afterwards to fail.

1. I am running tests that I know pass on everyone else's machine, including our build server
2. Not using IIS Express is not an option, as then my build environment would be inconsistent with the team's. Furthermore, these tests were running just fine not a week ago, so this shouldn't be a problem.
3. I have uninstalled and reinstalled Visual Studio 2013.5 to no avail.
4. I have uninstalled IIS 10 Express and installed IIS 8.0 Express to no avail. (I couldn't find any download/installer for IIS 10 Express, but that was definitely what was installed on the machine before.)
5. I have uninstalled Visual Studio 2015 entirely, in case it was causing conflicts with the 2013 install. Also, no avail.
6. All of our machines are identical builds, so I know this isn't a hardware problem.
7. My machine is running Windows 8.1 x64. The project is a mixed ASPX/MVC web project running .NET 4.5.1

I am quickly running out of ideas short of reformatting my hard drive and wiping everything off of the face of the planet - which seems extreme, but if that's my only option, then so be it.

Update

Here are the errors as shown in the event viewer:

ASP.NET 4.0.30319.0, 11:36:44 AM

An unhandled exception occurred and the process was terminated.

Application ID: /LM/W3SVC/1/ROOT

Process ID: 6072

Exception: System.Threading.ThreadAbortException

Message: Thread was being aborted.

StackTrace:    at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
   at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)

Application Error, 11:36:44 AM

Faulting application name: iisexpress.exe, version: 8.5.9748.0, time stamp: 0x5384d451
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17278, time stamp: 0x53eeb460
Exception code: 0xe0434352
Fault offset: 0x00012f71
Faulting process id: 0x17b8
Faulting application start time: 0x01d0d90283199962
Faulting application path: C:\Program Files (x86)\IIS Express\iisexpress.exe
Faulting module path: C:\WINDOWS\SYSTEM32\KERNELBASE.dll
Report Id: c3187027-44f5-11e5-82a2-a0481c829032
Faulting package full name: 
Faulting package-relative application ID: 

ASP.NET 4.0.30319.0, 11:36:48 AM

An unhandled exception occurred and the process was terminated.

Application ID: DefaultDomain

Process ID: 6072

Exception: System.Threading.ThreadAbortException

Message: Thread was being aborted.

StackTrace: 

.NET Runtime, 11:36:48 AM

Application: iisexpress.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Threading.ThreadAbortException
Stack:

Application Error, 11:36:48 AM

Faulting application name: iisexpress.exe, version: 8.5.9748.0, time stamp: 0x5384d451
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17278, time stamp: 0x53eeb460
Exception code: 0xe0434352
Fault offset: 0x00012f71
Faulting process id: 0x17b8
Faulting application start time: 0x01d0d90283199962
Faulting application path: C:\Program Files (x86)\IIS Express\iisexpress.exe
Faulting module path: C:\WINDOWS\SYSTEM32\KERNELBASE.dll
Report Id: c5aab60e-44f5-11e5-82a2-a0481c829032
Faulting package full name: 
Faulting package-relative application ID: 

Update 2

When catching first-chance exceptions and attaching to the IIS Express process, I get the following exception:

A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll

Additional information: Thread was being aborted.

This occurs when trying to call context.Response.Redirect("~/ErrorPages/AccessDenied.aspx", true); Other pages that redirect to this page can do so successfully.

Update 3

Here are the first-chance exceptions when turning off "Just My Code"

First

System.Globalization.CultureNotFoundException occurred
Message: A first chance exception of type 'System.Globalization.CultureNotFoundException' occurred in mscorlib.dll
Additional information: Culture is not supported.

Second

System.Web.HttpException occurred
  _HResult=-2147024809
  _message=Invalid file name for file monitoring: 'D:\Dev\Git\Qualtrax\Web\Content'. Common reasons for failure include:
- The filename is not a valid Win32 file name.
- The filename is not an absolute path.
- The filename contains wildcard characters.
- The file specified is a directory.
- Access denied.
  HResult=-2147024809
  IsTransient=false
  Message=Invalid file name for file monitoring: 'D:\Dev\Git\Qualtrax\Web\Content'. Common reasons for failure include:
- The filename is not a valid Win32 file name.
- The filename is not an absolute path.
- The filename contains wildcard characters.
- The file specified is a directory.
- Access denied.
  Source=System.Web
  ErrorCode=-2147024809
  WebEventCode=0
  StackTrace:
       at System.Web.DirectoryMonitor.AddFileMonitor(String file)
  InnerException: 

Third

System.Net.Sockets.SocketException occurred
  _HResult=-2147467259
  _message=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
  HResult=-2147467259
  IsTransient=false
  Message=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
  Source=System
  ErrorCode=10060
  NativeErrorCode=10060
  StackTrace:
       at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
  InnerException: 

Fourth

System.IO.IOException occurred
  _HResult=-2146232800
  _message=Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
  HResult=-2146232800
  IsTransient=false
  Message=Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
  Source=System
  StackTrace:
       at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
  InnerException: System.Net.Sockets.SocketException
       _HResult=-2147467259
       _message=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
       HResult=-2147467259
       IsTransient=false
       Message=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
       Source=System
       ErrorCode=10060
       NativeErrorCode=10060
       StackTrace:
            at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
            at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
       InnerException: 

Fifth (this one occurrs just before the crash):

System.Threading.ThreadAbortException occurred
  _HResult=-2146233040
  _message=Thread was being aborted.

Hope some of those help.

Answer 1

As it turns out, this answer to this other question solved my problem: https://stackoverflow.com/a/24880514/2689694

In short, because I had installed Visual Studio 2015, my IIS configuration had been modified to use a different pipeline mode. Those redirects in our code tended to pass in true as an overload, meaning that the response would end - which throws a thread aborted exception. The fix was that (as the link discusses) to use Context.ApplicationInstance.CompleteRequest() instead of the overload boolean. That means that it will now behave properly independent of the pipeline mode.