EPiServer version: 10.3.2
The easiest way to reproduce this error. At least in my case, is to start debugging the project via IISExpress. Wait until the start page has loaded. Shut down the debugging session and start up a new one. What will happen on the second startup is that the start page controller will receive a currentPage-instance that is not wrapped in a castle proxy, making all custom data .
I don't think IISExpress or debugging is the actual problem. We tend to see this issue turning up on our QA-deployment as well from time to time. That's a release build hosted on a real IIS.
I don't really know the quirks with castle proxies or EPiServer caching. But my investigation has lead me to believe that the object stored in cache can lose it's castle proxy wrapper somehow.
Calling CacheManager.Clear() whenever this happens solves the problem. The cache will be repopulated and the content loader will return castle proxies and cached castle proxies for some time. Eventually it will get corrupt again.
Hmm, very interesting. Never heard about this issue. What is actual object stored in cache?
Sounds a bit like this one, basically calling IContentLoader/IContentRepository before CMS has completed initialization.
I will see if I can find anywhere in the code where the content loader is possibly invoked early. We have a few scheduled jobs and custom init-modules that may be the culprits.