Application Crashes when Accessing Database

Question

I have a small web application which runs fine on my PC, but when I publish it to the server, the app crashes when querying the database.

I have narrowed it down to this line:

output = (List<Pallet>)db.Query<Pallet>(query, args);

Where I am using Dapper to query a table.

Normally when an error occurs it takes me to the shared ASP errors page, but here I just get a This site can’t be reached ERR_CONNECTION_RESET in Chrome.

I also noticed that in the Event Viewer an Application Error appears with Event ID of 100:

Faulting application name: w3wp.exe, version: 8.0.9200.16384, time stamp: 0x5010885f
Faulting module name: mso30win32client.dll, version: 16.0.4266.1001, time stamp: 0x55ba12f1
Exception code: 0xc0000005
Fault offset: 0x00088092
Faulting process id: 0x35a4
Faulting application start time: 0x01d2cce79551069b
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Program Files (x86)\Common Files\Microsoft Shared\Office16\mso30win32client.dll
Report Id: f044a40f-38da-11e7-9402-a4bf011a3e0b
Faulting package full name: 
Faulting package-relative application ID: 

Here is the method in GrvController:

public ActionResult Details(string grvNumber)
{
    var pallets = access.GetPallets(grvNumber);

    var grv = new Grv(pallets);
    Session["grv"] = grv;

    return View(grv);
}

And Access.GetPallets:

internal List<Pallet> GetPallets(string grvNumber)
{
    using (var db = new OleDbConnection(ConnectionString))
    {
        var query = Constants.GetGrvQuery;
        var args = new DynamicParameters();
        args.Add("@grv", grvNumber);

        var output = new List<Pallet>();
        try
        {
            output = (List<Pallet>)db.Query<Pallet>(query, args);
        }
        catch (Exception e)
        {
            Log.Debug(e.Message);
        }
        return output;
    }
}

Note that Exception e is never caught, and the application just crashes after a delay.

Has anyone experience this before? Does anyone know how I can go about debugging this?

Thanks in advance.

---

Update

I tried changing my GetPallets method to see if the issue was Dapper specific, but it is doing the same thing when calling OleDbConnection.Open().

I also noticed that in my event viewer, there is a constant stream of this application error:

Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. Reason: Could not find a login matching the name provided. [CLIENT: <named pipe>]

from source MSSQL$MICROSOFT##WID. Could it be that this is somehow related?

My application is set up to use a service account created in AD.

---

Update 2

Thanks to Austins comments, I believe its been narrowed down further to being some sort of permissions issue with an internal MS database. When I change the web app to run as administrator instead of my serviceQC account, it can access the database without any issues.

However, this is of course not good practise. I tried adding all of the groups in administrators "member of" tab in AD to serviceQC, but that doesn't help. Does anyone know how I can grant access to the MSSQL$MICROSOFT##WID database for a specific user?

Answer 1

After messing around with this for some time, I found the following option in IIS

Application Pool -> Advanced Settings -> Load User Profile

Where the description is

[loadUserProfile] This setting specifies whether IIS loads the user profile for an application pool identity. When this value is true, IIS loads the user profile for the application pool identity. Set this value to false when you require the IIS 6.0 behavior of not loading the user profile for the application pool identity.

After setting this to True, my application can now interact with the database.

Weirdly, after changing this back to false (I needed to make sure this was the cause), the app now no longer crashes, but instead just returns an empty List<Pallet> from the database (it does not appear to throw an error).

I found this answer which does some explaining as to what is going on, but as one of the comments mentions, setting this option probably has some security and performance implications.

I'm assuming there must be some other way to resolve my issue, but for now this will have to do.