Documentation:Debugging MDrivenServer Serverside actions

Debugging MDrivenServer Serverside actions

This page was created by Hans.karlsen on 2019-09-09. Last edited by Wikiadmin on 2026-07-29.

You can diagnose failing or slow server-side actions by capturing exception details in the ViewModel, correlating server jobs in the log, and inspecting current and recent work in MDrivenServer administration pages.

Start with the server-side job

A server-side job is a ViewModel action that MDrivenServer executes without a logged-in user. Before investigating an error, verify that the job is eligible to run:

Check that the server-side selection expression finds the objects you expect.
Check the action's enable or disable expression.
Check access groups. A server-side ViewModel has no logged-in user, so its access setup must allow execution by the server.
Open /admin/AdminAppPeriodicActions.aspx to see executed actions.

For example, if the log says Skipped <actionsname> due to enable==false <Viewmodelname> touched 0 objects, first check whether the enable/disable expression evaluates as intended, then check the ViewModel access groups and default access group.

For setup details, including server-side access-group patterns, see Documentation:Serverside actions. For periodic-action selection and execution behavior, see Training:MDrivenServer periodic server-side actions.

Save exception information in your model

You can add named columns and an action to the root ViewModel class to capture information when a server-side ViewModel throws an exception. This error-handling support was added in the September 2019 release.

When an exception occurs, MDrivenServer performs the available steps in this order:

Sets an ErrorInfo-prefixed column.
Sets an ExceptionInfo-prefixed column.
Calls an OnException-prefixed action.

The names are not case-sensitive, but each name must start with the stated prefix. You may omit any of these members that you do not need.

Add to the root ViewModel class	Requirement	What MDrivenServer does
`ErrorInfo`...	A string column, normally less than 255 characters	Stores error information.
`ExceptionInfo`...	A string column intended for longer text	Stores exception information, typically including a call stack. The text is truncated if necessary to fit the target attribute.
`OnException`...	An action	Runs after the two information columns have been set. The action can receive `ErrorInfo` and `ExceptionInfo` as string variables and use them in its logic.

Example: persist an error summary

Add the following members to the root class of the server-side ViewModel:

A string column whose name starts with ErrorInfo, such as ErrorInfo.
A longer string column whose name starts with ExceptionInfo, such as ExceptionInfo.
An action whose name starts with OnException, such as OnException.

Use the OnException action to process the supplied error strings in the way your model requires. If that action tries to send email, it must also have the columns required by the email action; otherwise, the email action fails.

Transaction behavior

Changes made by the server-side ViewModel before the exception are rolled back before the error-handling steps above are applied. Design OnException with this in mind: use the exception information for handling or recording the failure, rather than assuming earlier changes from the failed execution were saved.

Inspect activity in WorkInfo

Open /admin/WorkInfo.aspx to get an overview of MDrivenServer work over short and long time ranges.

Read the graph from right to left:

Work enters at the far right. The far-right edge represents work happening now.
Bright red shows currently running jobs at the fastest time scale. A short job appears as a dot; a job that runs longer appears as a line.
Bright-red activity passes across the full timeline in about one minute.
The other colors show the same work at slower time scales. Blue is the slowest scale and stays visible longer, but has lower time resolution.

Start with bright red when investigating a current problem. Then use the slower colors to determine whether the same job has been running repeatedly or for an extended period. A long duration, or work that remains ongoing, can indicate database locks, missing indexes, or poorly constructed server-side jobs.

Check WorkInfo through the API

The WorkInfo graph information is also partly available through an API endpoint:

https://your-host/api/ServiceAdmin_WebApi/CurrentWorkInfo

Authenticate with a Basic Authorization header for an MDrivenServer user. The response contains work entries with a name, start time, and duration. A duration of negative one second means that the work is still ongoing.

[
  {
    "Name": "Evolve",
    "Started": "2026-03-31T17:01:14.2785393+02:00",
    "Duration": "00:00:00.1238185"
  },
  {
    "Name": "Watch_MainTimerTick",
    "Started": "2026-03-31T17:01:24.1734076+02:00",
    "Duration": "00:00:00.0003750"
  }
]

Monitor entries with long durations and -00:00:01-style ongoing durations when diagnosing stalled work. Compare the entry name and timing with the server log and the WorkInfo graph.

Correlate entries in the server log

Open /admin/Log.aspx to inspect actions recorded by MDrivenServer. Several jobs can execute in parallel, so their log lines can be interleaved. Use the job number shown with a log entry to identify messages that belong to the same server job.

For example, when one action fails while other periodic actions continue, filter your investigation by that shared job number rather than reading adjacent log lines as one execution.

See Documentation:MDrivenServer log and Documentation:Turnkey and MDrivenServer logs for log access and related log troubleshooting.

Reproduce a server environment locally

If you have MDrivenServer source code and need to debug an environment locally, you can copy the server's compact settings database into your local development environment. This reproduces connection strings and other server settings that may be relevant to the failure.

The compact database is located at:

AppCompleteGeneric\AppCompleteGeneric.PServerIis\App_Data\DatabaseCompact.sdf

In the MDrivenDesigner Portal window, create a snapshot and download DatabaseCompact.sdf from the server. You can also obtain the file manually.
Preserve your local copy so that you can restore it later.
Replace the local development environment's DatabaseCompact.sdf with the downloaded server copy.
Reproduce and debug the issue locally.

Do not leave two MDrivenServers active against the same environment while investigating the issue. Two servers create two client-synchronization queues, which makes the behavior and diagnostic evidence harder to interpret. Stop the other server while you search for the error.

Debug related custom code

This page covers diagnosing server-side ViewModel execution. If the failure is in CodeDress or Turnkey generic code, use the dedicated debugging procedures instead:

Contents