Hi Jonathan,
never seen this. But some ideas. (better said: two ideas)
Before launching the Ax Client with a certain startup command, the AxHLink tool (the one assigned with the dynamics:// URL anchestor), tries to detect if a 'matching' Ax32 is running.
This is done by searching for a NamedPipe on the system (client) with a certain name. This Pipe is created if starting a Ax32.Exe client. The Pipe Name is built up from a prefix
'Dynamics\Event\', the matching ID (to support different clients running against different AOSses) and the so calles LogonSID
The 'matching ID' is taken from the following system parameter 'DrillDown Target' (in this example 33)
maybe it's a security issue for the user (not allowed to create a named pipe server or something)
Can you please start the Ax32.Exe (using the user which reported a malfunction)
and look if the named pipe server really exists.
Use (for example) PipeList.Exe Tool from SysInternals (Commandline-Tool)
https://technet.microsoft.com/en-us/sysinternals/dd581625.aspx
There should be an entry like.
As described the AxHLink tool searches for the existance of this pipe name and writes the 'command' to this pipe.
The DrilldownTarget ID is part of the URL
dynamics://33/?Drilldown_12345 (12345 is the InboxID(not the recID) of table EventInbox)
If no NP found Ax32.Exe is started.
Second idea: (seen sometimes)
Beside constructing the named pipe server on startup, this pipe is read by a timeout based operation.
This processes the command and reset the timeout (for the next call) afterwards.
I'm not sure, but I think sometimes this works only once (at least in earlier versions) . If a exception is thrown during processing of the command, the code for setTimeout isn't executed again.
Maybe you can post your results after investigation of the problem here.
regards
Douglas
