Memory Management issuein CRM Client for Outlook UR11 Critical Update

(0) Share

Report

Posted on by AdrianR

115

Hi,

We've just rolled out the critical update for CRM client for Outlook UR11 that was released by Microsoft to Windows Update last week. Part of the update was a change to how CRM windows opened, i.e. under a new CRM application process, this change also included a limit to the number of windows that could be opened in order to prevent an Out of Memory Exception.

Several of our users have reported reaching this limit and getting the following message:

--------------------------- Microsoft Dynamics CRM ---------------------------

Sorry, the application is low on memory so the form can not be opened. If you have any Microsoft Dynamics CRM for Outlook forms open, save and close them, and try again.

--------------------------- OK ---------------------------

However, in order to be able to open more windows the users have to close ALL open CRM windows. I have been able to reproduce this in our development environment.

Has anyone else experienced this problem? Does anyone know if Microsoft is aware of this problem? Does anyone know if anything can be done to fix this?

Thanks, Adrian

*This post is locked for comments

I have the same question (0)

All responses (8)

Answers (2)

Verified answer

JBirnbau on at

Like (0)

Report

Hi AdrianR,

This message is by design, and to better explain why, I'll do my best to cover how we've changed the design of the client in our most recent update. When the CRM client is first opened with the Critical Update (or Update Rollup 15 and beyond) installed, it spins up two new Microsoft.Crm.Application.Outlook.WebFormsHost.exe processes that host all CRM forms that are opened from within Outlook. The client then begins monitoring these processes for two separate memory thresholds - VirtualMemAvailableWarningThreshold and VirtualMemAvailableErrorThreshold. If you are using the 32-bit client, then the former threshold is set to 614MB by default (or 70% used of the 2GB available) and the latter threshold is set to 204MB by default (or 90% used of the 2GB available).

Based on these two thresholds, the Critical Update monitors for two scenarios:

Grid-to-Form Navigation: When a user opens a form from the grid, the client initially handles it in the first WebFormsHost process. When this first process reaches the 70% memory utilization threshold, the client transparently switches new forms opened from the grid to the second WebFormsHost process. When the second process reaches the 70% memory utilization threshold as well, the "low on memory" message you quoted above is surfaced to the end user.

Form-to-Form Navigation: When a user opens a form from within another opened form (i.e. through Advanced Find or Duplicate Detection), the client handles it in the same process that is handling the form from which it was opened. In this scenario, the client is unable to switch over to the second process even if the original has already hit the 70% memory utilization threshold. The first process is then allowed to reach the 90% memory utilization threshold before the "low on memory" message is surfaced to the end user. This message is raised to the end user even though the other process hasn’t even been used.

In either scenario, once the forms being handled by an existing process are closed, that process is discarded and a new WebFormsHost process is spun up in its place. Depending on how the users in your organization are making use of the client, they may be able to reduce the number of times this message appears by making a point of opening forms from the grid rather than through an existing form. Outside of that recommendation, though, the best advice I can provide would be to close the opened forms as they're no longer needed in order to allow the client to spin up a new process with an entirely new 2GB ceiling.

In Update Rollup 15, we will be introducing a number of additional enhancements that will lower the memory footprint that each form utilizes, which in turn will make these thresholds more difficult to reach. More enhancements will be made in Update Rollup 16 and beyond, as well.

Was this reply helpful? Yes No
AdrianR 115 on at

Like (0)

Report

Hi Jon,

Thanks for such a detailed answer. Before I accept it as the answer, could you explain the following:

1. closing forms that have been opened does not appear to release the memory that was used by the forms, is this by design? If so, can I recommend changing the design!

2. As I have been testing this functionality I have been able to get three WebFormsHost processes running at the same time with active forms.

3. I'm using the 32bit client and have seen the processes running quite happily with one of the consuming 1.6GB memory... based on your description above I couldn't determine if this should be possible or if it should error.

4. Several of our users are getting the error message when opening only a couple of forms (I'm collecting more details on this), but when testing myself I am able to open 30+ forms without problems.

Whislt I appreciate the benefits that this approach will bring in the future, I think there are some improvements to be made and look forward to future updates.

Thanks, Adrian

Was this reply helpful? Yes No
Verified answer

JBirnbau on at

Like (0)

Report

Hi AdrianR,

No problem! I'll do my best to address your follow-up questions:

1. Some memory does get left behind when a form is closed and isn't always entirely freed up by standard garbage collection. This is something we are targeting for Update Rollup 15, however the amount of memory that is left behind can be significantly increased by org-specific customizations. Therefore, it's possible that any enhancements made in future Dynamics CRM patches will not have the same impact across all environments. My recommendation would be to make sure that any data that is being pinned or event handlers that are being called by custom code are properly disposed of.

2. I have seen certain scenarios where this can happen, and I believe this largely depends on how you're opening the forms and how many forms you have open at a given time. If you close the open CRM forms, the client should adjust the number of processes and their utilization accordingly.

3. If you enable client-side tracing through Diagnostics (Advanced Troubleshooting tab) with the Critical Update installed, there will be a new WebFormsHost log file placed in the %USERPROFILE%\AppData\Local\Microsoft\MSCRM\Traces folder. The callstacks in this log file will indicate the client's Virtual Memory calculations and the results of the new CheckMemoryThreshold method. This method returns a "Memory Threshold Hit" message when it reaches one of the configured thresholds. Whether the client moves to the second process or creates a new one will be determined by the scenarios outlined in my previous post.

4. I have done a lot of stress testing myself, but have not encountered any memory-related error messages after opening such a small number of forms. If you can reproduce this behavior, I would encourage you to open a support case so that it can be investigated more thoroughly.

Was this reply helpful? Yes No
AdrianR 115 on at

Like (0)

Report

Hi Jon,

Thanks for taking the time to answer this. When I posted the original question I hadn't expected to get such a technical and indepth answer.

Kind rgeards,

Adrian

Was this reply helpful? Yes No
AdrianR 115 on at

Like (0)

Report

Hi Jon,

We're getting reports from many users about this issue.

It seems that once you have hit the limit on one of the processes it then prevents new windows being opened form the main Outlook window in the second process. For example, I hit the limit on one process at 1.2GB but the second process only had 33MB memory usage, however, I am unable to open new windows from Outlook without closing all the CRM windows in the process that has hit the limit - for end users this esentially means closing all windows.

I have done some testing on memory garbage colletion and found that closing a form results in less than a third of the memory being recovered. The most basic for we have in our system has only two text boxes on it and no Javascript. Each time I open one of these it increases memory usage by 18MB but closing it only releases 5MB. This appears to be the general pattern, e.g. the email activity form uses 30MB but closing it only releases 8MB. Our most heavily customised form uses 37MB and releases 12MB when closed.

These two factors together mean that sooner or later users are going to hit the limit. As I'm sure you can appreciate this is extremely frustrating for our users.

I'm more than happy to open a support call about this but is that going to result in getting any improvement in the situation quicker than waiting for UR15?

Kind regards,

Adrian

Was this reply helpful? Yes No
JBirnbau on at

Like (0)

Report

Hi AdrianR,

The client should roll over to the second process for new forms if you're opening them directly from the grid. If new forms opened from the grid (as opposed to a separate window/form) are not utilizing the second process, then I would definitely recommend opening a support case with us as this is something we would want to investigate more thoroughly.

In regard to your memory usage results, memory cleanup is being targeted in Update Rollup 15 and 16, so you should see a measurable impact during similar tests after the next two patches, specifically. If the "low on memory" message is being surfaced to your users during a typical workday, then I would recommend that they close the currently opened CRM forms to allow the client to break down the current WebFormsHost process and spin up a new one. The client is not able to do this while there are forms open, otherwise they would all inadvertently disappear for the end user without any warning.

Was this reply helpful? Yes No
MKMASG 20 on at

Like (0)

Report

Hi AdrianR,

I'm wondering if you got a solution or opened a ticket with Microsoft for this.

We are about to install the CU to resolve the issue with recieving the message:

"Sorry, the application is low on memory so the form can not be opened. If you have any Microsoft Dynamics CRM for Outlook forms open, save and close them, and try again"

However, after reading your post, I'm not sure if this will fix the problem.

Unfortunately, we can't reproduce this issue in the group, but many users are getting it more often. This started to happened in the last 3 weeks. Not sure what it was.

Any feedback will be appreciate it.

Thanks,

Mariella Mas

Was this reply helpful? Yes No
AdrianR 115 on at

Like (0)

Report

Hi Mariella,

The UR11 Critical Update did solve the problem with Outlook crashing all the time, however we have been getting the message "Sorry, the application is low on memory so the form can not be opened. If you have any Microsoft Dynamics CRM for Outlook forms open, save and close them, and try again" quite a bit.

I haven't yet started testing Update Rollup 15 yet, as we had a number of other projects to complete.

One issue, and I don't know if it is fixed in RU15, is that whilst the update runs two processes for opening nrew windows, over time they leak memory and if one of the hits the memory limit a third process will be started but for some reason the old one will not be killed and this prevents new windows opening with the message above. The only way to get around this is either killing the process using task manager or closing Outlook.

I'm going to be starting testing UR15 later this week and I hope some of the memory leaks will have been fixed.

Kind regards,

Adrian

Was this reply helpful? Yes No