You can use this guide to diagnose an MDriven Turnkey or MDrivenServer application that does not start, returns an IIS error, or repeatedly restarts under IIS.
Start with the error IIS is hiding
IIS can route an error back into the application that failed, which hides the original startup error. Temporarily enable detailed IIS errors while you investigate.
- Open the deployed application's
web.config. - Find the
httpErrorsconfiguration that routes errors through the application. - Temporarily remove this section:
<httpErrors errorMode="Detailed">
</httpErrors>
- Request the application again and record the complete status code and error text.
- Restore the intended error handling after you have resolved the issue. Detailed errors can disclose implementation information to clients.
For a legacy application using system.web, enable compilation debugging during diagnosis:
<system.web>
<compilation debug="true" />
</system.web>
Do not treat a browser error page as the only diagnostic record. Check the logs described below before changing multiple IIS settings at once.
Check logs before changing configuration
Use the time of the failed request to correlate IIS and application logs.
| Location | What to check |
|---|---|
| Windows Event Viewer, Application log | Startup errors reported by IIS or the application host. For example, an ASP.NET Core startup failure can be reported here. |
| IIS log files | The request status code and the time at which IIS received the request. |
C:\inetpub\wwwroot\MDrivenServer\logs
|
MDrivenServer log entries, when MDrivenServer is deployed in this default location. |
C:\inetpub\wwwroot\MDrivenTurnkey\logs
|
Turnkey log entries, when Turnkey is deployed in this default location. |
If your site is deployed elsewhere, check the logs directory below that application's physical path. A repeated sequence of startup entries is evidence of a restart loop; a single startup error is more likely an initial configuration, runtime, or access problem.
Diagnose a startup failure
1. Verify the IIS deployment inputs
Confirm that IIS points to the intended physical folder and that the application uses the intended application pool. Then check that the URL in the IIS binding is the same URL configured for IIS startup in App_Data/CommandLineOverride.xml.
For example, if the site binding exposes http://localhost:80/MDrivenServer, the URL configured in CommandLineOverride.xml must use that same URL. A different host name, port, or application path can prevent the application from starting as intended.
For the complete setup of CommandLineOverride.xml, MDrivenServerOverride.xml, bindings, and separate MDrivenServer and Turnkey application pools, see Documentation:Deploying MDriven Server & Turnkey Core on IIS.
2. Check the application pool runtime mode
For the IIS Core deployment described in Documentation:Deploying MDriven Server & Turnkey Core on IIS, the MDrivenServer and Turnkey application pools use No Managed Code. Do not diagnose a Core deployment using the older .NET CLR 4.0 application-pool guidance intended for the Windows installation path.
If the application reports HTTP Error 500.30 - ANCM In-Process Start Failure:
- Install or reinstall the required ASP.NET Core Hosting Bundle.
- Restart IIS.
- In IIS Manager, verify that
AspNetCoreModuleV2appears under IIS Modules. If it is absent, the hosting bundle is not installed correctly. - Request the application again and check Event Viewer and the application log directory for the next error, if any.
See Documentation:Deploying MDriven Server & Turnkey Core on IIS for the deployment prerequisites and IIS configuration.
3. Verify application-pool file access
The application runs with the application pool identity when it accesses the file system. Grant that identity read and write access to the deployed application folder. During diagnosis, grant the application-pool user full control to rule out file-access failures, as documented for the Core IIS deployment.
For example, if the pool is named MDrivenTurnkeyAppPool, verify access for IIS APPPOOL\MDrivenTurnkeyAppPool on the Turnkey site folder. The account must be able to write where the application needs to create logs and use temporary files.
The Windows installation guidance also notes that the application-pool user needs access to the application folder and that the Logg subdirectory must allow Write and Modify access. See HowTos:Installing MDriven Server on Windows for the Windows/IIS installation context.
4. Verify the binding and certificate
Confirm that the hostname and port in the site binding match the URL used by the application configuration. If the deployment uses HTTPS, the certificate must be valid for the MDrivenServer: MDrivenServer communicates with itself and must accept its own certificate.
A certificate name mismatch can therefore prevent internal communication even when a browser lets you continue past a certificate warning. Use the certificate's issued-to name when accessing the application and configure the corresponding IIS binding.
5. Check server connectivity
If the application starts but cannot connect to MDrivenServer or its database, check the configured connection information and network connectivity. For Turnkey, also verify the MDrivenServer URL and credentials in App_Data/MDrivenServerOverride.xml. Keep this check separate from an IIS startup failure: resolve the IIS error first, then resolve the connection error shown in the logs.
Prevent recurring application-pool interruptions
An application that starts and then stops at a predictable time is often being recycled by IIS rather than failing its initial startup. Inspect the application-pool recycle configuration and compare the recycle time with the timestamps in the logs.
For an application pool that must remain available, consider these settings in IIS Manager: select the application pool, then select Advanced Settings.
| Setting | Recommended diagnostic or operational value from the Windows installation guidance | Why it matters |
|---|---|---|
| Start Mode | AlwaysRunning
|
Keeps the pool configured to start rather than waiting for the first request. |
| Disable Overlapped Recycle | Enabled (1)
|
Prevents an old and new worker process from overlapping during recycle. |
| Idle Time-out Action | Suspend rather than terminate | Avoids terminating the application when it becomes idle. |
If restarts occur at the same time every day, check scheduled recycle settings as well. Disable overlapped recycle where parallel execution would be harmful. An overlapping old and new process can cause server-side jobs or SysAsyncTickets to be entered and started in parallel, and another process can hold a VistaDB lock.
Use separate application pools for MDrivenServer and Turnkey to isolate their processes, as described in Documentation:Deploying MDriven Server & Turnkey Core on IIS.
Fix a restart loop caused by file-change notifications
IIS can restart an application after it detects many file changes. MDriven controls site updates, so its applications use fcnMode="Disabled" to disable this file-change-notification behavior.
If the logs report that IIS or an Azure Web App is restarting because of overwhelming change notification or IIS configuration change, follow Documentation:IIS application restart problem. This is especially important when MDrivenServer is installed in an __MDrivenServer directory but there is no Turnkey application and web.config at the IIS site root. That page provides the required root-level web.config example.
Restart IIS only after recording the error
After you correct a prerequisite, configuration, or permission problem, restart IIS from an elevated command prompt:
iisreset
Run this after you have captured the failing error and log entries. Restarting first can remove useful context and does not correct a missing hosting bundle, mismatched URL, invalid certificate, or missing folder permission.
Escalation checklist
When you need help from an administrator or support contact, provide:
- The exact URL requested and its IIS binding.
- The full HTTP status and detailed error text.
- Relevant Event Viewer Application log entries.
- The corresponding MDrivenServer or Turnkey log entries.
- The application pool name, identity, runtime mode, and recycle settings.
- Whether the issue is an initial startup failure, a predictable recycle, or a repeated restart loop.
- Whether the deployment is Core IIS deployment or the Windows installation path.