Never seen that command, though the output is clearly AI generated. It appears that this is its rational for blaming a particular driver:
The OpenText OES Client installs deep kernel components (minifilter drivers and network redirectors) that hook into the I/O manager or the memory manager’s mapped file routines (exactly what’s crashing: MiGatherMappedPages). "uninstalling the client did provide a slight improvement, though the error still occurs occasionally". And seems to imply that removing the OES client eliminated a major source of memory corruption in the paging path but some remnants appear to be there.
I have no idea what a “deep kernel component” is…And if it’s uninstalled but the system still crashes in the same way I’m not sure how that implies removing it eliminated a “major source of memory corruption”.
So, I don’t see anything here that provides any sort of definitive reason why one particular driver is the culprit. I mean, it could be of course, but I’d probably need to review the code and possibly try to reproduce this crash to have any more insight.
I believe after Micro Focus acquired Novell, and then OpenText acquired Micro Focus, all of Novell’s networking components were rebranded but the same technology stack and same kernel drivers stayed. And this driver it still there (quite up to date, by the way):
no one who builds debuggers would ever write that as an output. That sounds like what is called AI - which is not intelligence, but adaptive heuristic
in any event, there is nothing here that points to a definitive cause. The short answer is that they don’t know - it is a guess. The veracity of the guess depends on how many times a similar failure has been observed. But the similarity in this case depends less on the mode of failure (null pointer, free after use, buffer overrun etc.) as it does on the specific vendors / modules that might be involved
Thank you for your suggestions. We are reviewing all memory allocations, including MDL-related allocations. Request you to share if we could share the drivers with you.
I’m happy to keep providing ideas I might have here within the constraints of a public support form…A code review or deeper analysis into this issue would fall more into the realm of professional services (it can be time consuming, may require NDAs, etc.). We’ve certainly had successful engagements like this in the past and if you’re interested you can contact Dan Root (dan at osr.com) for more info.
Thank you for your reply. Sorry for the late response—I was off for two days. I will discuss this with my managers and check if we can proceed. Thank you.