Art Of Creation - Dynamics AX Blog » RPC

Error 1740: The endpoint is a duplicate

Klaas Deforche — Wed, 06 May 2009 11:42:43 +0000

Today, I came across the following error when trying to start an AOS:

Error 1740: The endpoint is a duplicate

This error occurs when the port that is specified in the server configuration of the AOS is in use by another process.
You’ll also find an entry in the event log on the AOS:

Object Server 03: RPC error: The Dynamics Server could not be started because TCP Port 2752 is already in use.

To figure out what process is using the port, you can use the Netstat command on the server. You’ll find something like this if an AOS is using the port:

TCP AOSServer:2752 DBServer.domain:ms-sql-s ESTABLISHED

It is possible that an other process is using that port, so either terminate that process or restart the AOS that’s occupying the port.
When you have more then one AOS on the server, the problem is figuring out what AOS is using the port.
You can search all server configurations for the port, but in my case, an AOS was connected to the wrong port because of a bug of some sort, so I used a program called CurrPorts.
CurrPorts shows you more information than the Netstat command, and gives you the option to terminate a TCP/IP connection.
I only needed to restart the AOS that was using the wrong port and the problem was solved.

AOS crashed when importing XPO

Klaas Deforche — Wed, 22 Apr 2009 21:26:49 +0000

A colleague came up to me today with a problem. She was trying to import an xpo file, and when she ticked the check box ‘Show details’ in order to compare the objects in the xpo file, the Dynamics AX client crashed. No message was shown, the application just quit. It was also impossible to reconnect to the Application Object Server because the AOS had crashed as well. When you restarted the AOS, you could easily reproduce this scenario by repeating the above steps.

Sometimes, the following message was logged in the event log on the client, basically informing you that the AX client had crashed:

Faulting application ax32.exe, version 5.0.1000.52, stamp 490c41fb, faulting module unknown, version 0.0.0.0, stamp 00000000, debug? 0, fault address 0x0bbf0b3c.

In the event log on the server an other message was logged, but not every time the AOS crashed:

Object Server 16: RPC error: Client provided an invalid session ID 3

From what I understand, this message is logged when a client sends an RPC request to a server that has ended the session for this client, which would be the case if the AOS crashed.

Once again, the event log is pretty useless. The real problem lies in the application files, more specifically the Microsoft Dynamics AX Label Index files. These are the files that have the extension .ali. For some reason, one or more of these index files are corrupt, and this causes the import process to fail, and the AOS to crash. At the time, the AOS server was low on diskspace, and that could be the cause of the corrupt index files. Luckily, index files such as ali files can be deleted when the AOS is down, and will be rebuilt when the AOS is started.
After all label index files were deleted, and the AOS restarted, the xpo could be imported, and the AOS didn’t crash anymore.

So, when the AOS crashed when you are trying to import an xpo file, stopping the AOS, deleting the ali files from the application directory and restarting the AOS might be the solution.

WinAPI, RPC 1702 and FindFirstFileW

Klaas Deforche — Wed, 08 Apr 2009 21:39:50 +0000

A very common scenario when doing interfaces with other applications, is to have a directory where one application places files, and the other one picks those up and processes them.
Let’s say some application want to interface with Dynamics AX, one way, from that application to AX. That application will drop files of a specific format, say *.txt, in a directory. You’ll want to have a batch job in AX that checks that directory every 5 minutes for those files. When your batch job finds those files, it will open them and do something with that data, then move them to an other directory, so you don’t process them twice.

Now the first thing you’ll probably think of (well, I did…), is to use the class WinAPI. This class has some useful static methods for checking if folders or files exist, finding files with a filename of a certain format. Just the kind of thing we’re looking for. Your code might look like this:

static void loopfilesWinApi(Args _args)
{
str fileName;
int handle;
str format = "*.txt";
;

if(WinApi::folderExists("C:\\Temp\\"))
{
[handle,fileName] = WinApi::findFirstFile("C:\\Temp\\" + format);
while(fileName)
{
//currentfileName = fileName;
info(filename);
filename = WinApi::findNextFile(handle);
}
WinApi::closeHandle(handle);
}
}

That’s perfect. It checks a directory, in this cas C:\temp, for files with the extension txt… until you try to run this in batch. Your batch will have the status error, and there will be an entry in the event log saying:

RPC error: RPC exception 1702 occurred in session xxx

That error message is very misleading, but Florian Dittgen has a nice blog entry about this, that explains why this goes wrong: WinAPI methods a static and run on client. In batch, you can not use these client methods.
But hey! There is a class called WinAPIServer, surely this runs on server, right? Correct, but a lot of the methods available in WinAPI are missing in WinAPIServer. You can however extend the WinAPI server class by copying methods from the WinAPI class and modifying them a bit. Let’s try that.

This is what the WinAPI::FindFirstFile() method looks like:

client static container findFirstFile(str filename)
{
Binary data = new Binary(592); // size of WIN32_FIND_DATA when sizeof(TCHAR)==2
DLL _winApiDLL = new DLL(#KernelDLL);
DLLFunction _findFirstFile = new DLLFunction(_winApiDLL, 'FindFirstFileW');

_findFirstFile.returns(ExtTypes::DWord);

_findFirstFile.arg(ExtTypes::WString,ExtTypes::Pointer);

return [_findFirstFile.call(filename, data),data.wString(#offset44)];
}

As you can see, this method uses the function FindFirstFileW from the Kernel32 dll located in the folder C:\WINDOWS\system32. Let’s copy this method to WinAPIServer and modify it to look like this:

server static container findFirstFile(str filename)
{
#define.KernelDLL('KERNEL32')
#define.offset44(44)

InteropPermission interopPerm;
Binary data;
DLL _winApiDLL;
DLLFunction _findFirstFile;
;

interopPerm = new InteropPermission(InteropKind::DllInterop);
interopPerm.assert();

data = new Binary(592); // size of WIN32_FIND_DATA when sizeof(TCHAR)==2
_winApiDLL = new DLL(#KernelDLL);
_findFirstFile = new DLLFunction(_winApiDLL, 'FindFirstFileW');

_findFirstFile.returns(ExtTypes::DWord);

_findFirstFile.arg(ExtTypes::WString,ExtTypes::Pointer);

return [_findFirstFile.call(filename, data),data.wString(#offset44)];
}

Three things have changed here:

“Client” has been change to “Server” so it can run on server;
The code has been changed to use the InteropPermission class; this is required because the code runs on server;
Initialization of the variables is moved to after assertion of the InteropPermission.

When you test this in batch (running on server), this will work, and you can do this for all WinAPI methods in the examples above… until you try this on a x64 architecture. You’ll receive a message saying that an error occurred when calling the FindFirstFileW function in the Kernel32 DLL (the exact message slipped my mind).
The problem is described on the Axapta Programming Newsgroup. You can code your way around this problem, but I think the message is clear: don’t use WinAPI.

Instead, use the .NET Framework System.IO namespace (watch out for lowercase/uppercase here), in our case in specific, System.IO.File and System.IO.Directory.
I get this nice code example from Greg Pierce’s blog (modified it a bit):

static void loopfilesSystemIO(Args _args)
{
// loop all files that fit the required format
str fileName;
InteropPermission interopPerm;

System.Array files;
int i, j;
container fList;
;

interopPerm = new InteropPermission(InteropKind::ClrInterop);
interopPerm.assert();

files = System.IO.Directory::GetFiles(@"C:\temp", "*.txt");
for( i=0; i<ClrInterop::getAnyTypeForObject(files.get_Length()); i++ )
{
fList = conins(fList, conlen(fList)+1, ClrInterop::getAnyTypeForObject(files.GetValue(i)));
}

for(j=1;j<= conlen(fList); j++)
{
fileName = conpeek(fList, j);
info(fileName);
}
}

This will run on client and on server without any problems. To have clean code, you could create your own class, just like WinAPI, but using the System.IO namespace. That way, you can reuse this code and save time.

Conclusion: abandon WinAPI, and use System.IO instead.