Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Web Server agent 'Shared memory version mismatch' issue


I know that it is highly recommend to restart app process after fixpack or upgrade so that agents also is upgraded.

However for the JVM and .Net agents the old agents works fine and gets updated seamlessly when the app is restarted next time.

For the EWS we see that the agent update is not that easy, we have to coordinate a primary agent restart and then the web server process restart to get the secondary updated. Else we see the error 'Shared memory version mismatch'.

My question is old agents works with new collector why cannot the old web server secondary agent work with the new primary agent or wise versa (newer secondary can work with old primary). If this works then we could follow the normal app recycle and at a later point restart the primary agent from the server console.

Primary and secondary agents are both form dynatrace so can't we get it work with different versions?



Dynatrace Pro
Dynatrace Pro

I think a better question might be can we suppress the secondary agents to not upgrade until the primary is reset? This way we will absolutely avoid this issue and have the primary agent control the roll out of a new version

I think Kyle is right 🙂

I like the idea,

Bottom line is we need some solution because even for a small minor fix pack roll-out we have to plan an application downtime. Web servers are internet facing components less the change the better.

I still wonder why these two agents are complaining on even a minor version difference. Does this has to be that tightly coupled?

Could there be a better solution in which secondary and primary can be restarted and upgraded in any order? at-least for minor version changes.


Dynatrace Pro
Dynatrace Pro

The primary and secondary agent share memory. I think we force you to update both agents to ensure that both agents are able to understand how the shared memory is structured. If for any reason the memory is not understood the same way by both agents, this would cause one of them to crash.

Sreerag, you may want to post this idea as a request for enhancement (Idea section of the forum).

Dynatrace Champion
Dynatrace Champion

hi everybody,

just as a heads-up: this also caused me some headaches in the past, already. it might have made sense in the past when the shared memory format was changed a lot, but currently it's causing mostly troubles with updates/upgrades.

good news is however, that we already have a solution and far better approach to this primary-secondary concept that we're working on. this will make it most probably into one of the next releases.


Thanks Christian, good to know engineering team alreday have a better solution for this.

We still face this issue for every upgrade, Also we are able to timely upgarde dynatrace because it require web server downtime to recycle.



I've been facing the same issue and looking in this thread if anyone have same issue or any solution on it, concurrently I've raised support ticket


Hello @Munawar S.

The most common root cause for this issue is that primary agents are not restarted after an update has been installed. The secondary agents will receive an update when a workprocess is restarted. The webserver primary agent however need to be restarted manually to apply the update. If the primary agent is not restarted, the secondary agents can have a new version than the primary agent, therefore causing this problem.

Have a look on the below documentation.