Native Client “Could not load assembly” error in VMware GemFire 9.x
Article ID: 294432
Updated On:
Products
Issue/Introduction
With VMware Gemfire Native Client 9.x, some users have encountered log messages warning "ManagedAuthInitializeGeneric: Could not load assembly" which are often associated with some connectivity issues. This article will summarize how to troubleshoot a Native Client with “Could not load assembly” errors.
The Native Client “Could not load assembly” error has appeared in logs from .Net applications. Sometimes this warning is nothing to worry about. However, when the connection is expected to be authenticated this exception will prevent the connection from properly authenticating. If the server does not require authentication, the server will allow the unauthenticated connection.
Environment
Resolution
In some instances, it was observed that the application pool crashes when invoking the Pivotal.GemFire.dll (32 bit) and the application responds with 503 - Service Unavailable error.
Below is the error logged in event viewer:
Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7a5f8 Faulting module name: Pivotal.Gemfire.dll, version: 9.2.1.10, time stamp: 0x5b686b43 Exception code: 0xc0000005 Fault offset: 0x0023a00a Faulting process id: 0x2cf8 Faulting application start time: 0x01d573d37e5edcc9 Faulting application path: ......
Resetting the application pool may cause the error to disappear for a period, only to resurface again later. Being an intermittent issue it can be hard to troubleshoot. However, in some instances, debugging revealed the following issue as the cause:
$exception
{"Attempted to read or write protected memory. This is often an indication that other memory is corrupt."}
System.AccessViolationException"
warning 2019/09/27 03:36:43.487035 Eastern Daylight Time ABCDEFGH123456:12345 54321] Authentication required in handshake with endpoint[123.45.6.789:8581]: ManagedAuthInitializeGeneric: Could not load assembly: Customer.GemFire.Auth
In this case, Customer.Gemfire.Auth is the assembly of the user's AuthInitialize implementation, which ManagedAuthInitializeGeneric is attempting to load and failing. This will likely lead to an exception being thrown in the AuthInitialize code, such as in the GetCredentials call.
Even if it does not throw an exception, it seems very unlikely that ManagedAuthInitializeGeneric is able to send back proper credentials from the GetCredentials call. At best, this will result in the auth failing, causing the app to report back an error.
As a worse case, the app could continue on without proper credentials causing the server to receive a message without a security ID at the end and close the connection. This usually leads to a timeout exception in the native client.
In order to troubleshoot such issues, the following artifacts may be needed:
1. Client logs from the .Net application
2. Crash dump collected at the time of the issue
Resolution
1. Check the application logs to see whether the Native Client application is running on a supported operating system - this issue often happened in windows7 sp1 (build 7601) which is not certified for Gemfire Native Client v9.2.1.
2. Collect a core dump when the Native Client application is running on a supported OS and this issue happens.
3. As the temporary resolution, make sure the server does not require authentication so that the server will allow the unauthenticated connections.
4. As a long term resolution, upgrade to Native Client 10.x, where the Gemfire Native Client does not require the AuthInitialize object to be placed in it’s own DLL.
Feedback
