D
dbeavon
Guest
>> The error that started this whole discussion (Error loading the .NET runtime. (14081)) happens when we first need to initialize the CLR Bridge and that happens on the first call to anything in .NET When you say the "first call to anything in .NET", then are you referring to the first call in the entire life of the agent process? That doesn't seem relevant. That had happened many days ago and there have been many tens of thousands of calls to .Net methods since then. But it appears that we are still encountering the same intermittent message in the logs "Error loading the .NET runtime" in association with that same MS-agent process ID. We churn thru the individual ABL sessions daily, because they are restarted on a regular basis (eg. when they become idle, are trimmed, and then are started when needed again ). But the outer agent process has been running over the course of several days. Given that the appdomain was loaded and initialized many days ago, it doesn't make sense for us to be getting the message "Error loading the .Net runtime". I suspect the message is trying to describe a different problem which is ABL-session-specific. I still think that the new ABL sessions might be having trouble hooking into the pre-existing .Net runtime. As far as the load factor goes, I'm wondering if there is contention between ABL sessions as they try to hook into the pre-existing runtime. The more rapidly the ABL sessions are started, the more likely we might encounter errors? Will the parameter which you referenced, -preloadCLR, affect the behavior of all the individual ABL sessions, or does it only impact the outer agent process (by initializing the CLR app domain on a one-time basis)? That parameter was referenced in the forums earlier, and the developer said it didn't change matters and they continued to see this same message ( see community.progress.com/.../34331 ) I have opened a tech support case on this, given that I'm a long way from finding the root cause on my own. I'd like to at least have a work-around that prevents these errors as much as possible, since I think they are disruptive when a few of our users encounter them each day. My tech support engineer wants me to supply a consistent reproducible and I still don't have one. Do you have any clues about how I might create a reproducible, even an artificial one? I was going to focus on my theory that this is related to a synchronization problem, but you don't seem convinced. Based on your experiences of this message, did you have any theories about how to recreate it on demand? As a side, I also opened another tech support case (00470446) about a substantial memory leak in the ms-agent process that seems to be related to the CLR bridge. It is pretty clear that there is a memory problem, given that the CLR managed memory dump can be opened in the VS debugger and we can see hundreds of rooted references (rooted via Progress.ClrBridge.ProMarshal). Currently we are killing agent processes only once a week. But as we migrate more of our applications from "classic" to pasoe, we are probably going to need to do that daily.
Continue reading...
Continue reading...