In this blog HSD’s Dynamics 365 Technical Consultant – Ash Dason, describes an issue he recently experienced when a plugin was misbehaving on a system he was working on. Ash also outlines the steps he took to identify the root cause of the problem and how he resolved the issue.
A plugin with custom code wasn’t firing on production environment.
The plugin was registered against a custom entity. Its purpose was to create associated records depending on said business logic. The environment was D365 on premise. We were able to create records without the plugin registered, but when it was registered the request timed out. The code is as follows:
The plugin was failing on the step where it was attempting to get the service (highlighted).
When a plugin hangs for more than two minutes the system is supposed to present an error to the user (unless the D365 configurations have been updated). In this scenario, not even the two minute timeout error occurred; the system just froze.
1. Initializing the plugin with Isolation Mode = none didn’t help.
2. Turning on tracing and investigating the logs didn’t provide any clues as to why the issue was happening.
3. We changed the service account that was running the CRM sandbox service and the plugins worked
Since we knew the issue was related to the service account, we installed Process Monitor to get a better understanding of what was going on.
The CRM Sandbox service was in “Running” state in the Windows services MMC. But there was no connection to the database in SQL Profiler (or attempts) and Process Monitor showed that no connection to the database was blocked, indeed the connections wasn’t even started by the Sandbox Service. But there was no evidence in the logs (Event Viewer, CRM Trace Logs) that registered this event
An error we found in Process Monitor was “file not found”. Upon further investigation we found the user folder for the service account running the CRM sandbox service was different (the folder name had a white space in it) to where windows stores the user profile (C:\Users\…). This made the sandbox slow to start and generate error as file not found in Process Monitor.
We changed the CRM Sandbox service to a different account temporarily. This allowed us to delete the corrupt user profile folder located at C:\Users. And then we let the system recreate it automatically. We updated the CRM Sandbox service again to use the correct service account and after this everything worked as expected.