EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Delphi XE Demo ProcMon Windows 7 Error 102

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
Posted: 07/10/2012 17:01:36
by Steffen Groth (Standard support level)
Joined: 07/09/2012
Posts: 1

Hi ,

I get when I start the demo immediately ProcMonView error 102
stdProcMon.exe is installed as a Windows service and runs.
Windows 7 Prof SP1 32-bit Delphi XE.

Under Windows XP everything works

Posted: 07/10/2012 23:21:58
by Eugene Mayevski (EldoS Corp.)

You need to modify MessengerName property of the MMF transport in both the server and the client.

On the server "GLOBAL\" prefix must be added to MessengerName. On the client "SESSION\1\" prefix should do the job (GLOBAL\ would also work if your account has admin rights).

This is because the service and the application are in separate sessions in Windows 7.

Samples will be updated for MsgConnect 2, which is being worked on now and will be released in Autumn.

Sincerely yours
Eugene Mayevski
Posted: 07/31/2012 20:27:48
by Yves Roulet (Standard support level)
Joined: 01/12/2012
Posts: 9


I have the same problem then Stefen Groth and I modify the MessengerName with prefix "GLOBAL\" on server and "SESSION\1\" on the client but now the error is:
"creation of memory mapping access mutex failed" what's happen?
Posted: 07/31/2012 22:16:01
by Eugene Mayevski (EldoS Corp.)

Either it's a permissions problem or your application doesn't run in session 1 (this can happen if you are in terminal environment). Assuming that the problem happens for you in Delphi, you can try to debug the source code to get the eact reason. Find this error message in MCMMF.pas and put a breakpoint there. Then expect the error code that causes the message and the exception to appear.

Sincerely yours
Eugene Mayevski
Posted: 08/01/2012 07:18:21
by Yves Roulet (Standard support level)
Joined: 01/12/2012
Posts: 9

Hi Eugene,

My delphi is instaled in a VM and when i Debug I found wher the execption occurs:

FMMFFreeMutex := CreateMutex(pSA, true, PChar({$ifdef MC_UNICODE_VCL}UnicodeString {$endif}(Owner.MessengerName) + '_MMFFreeMutex'));
I := GetLastError;
if ((FMMFFreeMutex <> 0) and (I = ERROR_ALREADY_EXISTS)) or ((FMMFFreeMutex = 0) and (I <> 0)) then
if FMMFFreeMutex <> 0 then
raise EMCError.CreateCode(MCError_MutexCreationFailed);

The I have a 3 value and looking for the error description i found that is ERROR_PATH_NOT_FOUND. Can you explain me the reason? Can you suggest me a easy way to known the session?

Posted: 08/01/2012 07:24:31
by Eugene Mayevski (EldoS Corp.)

Are you running the sample on Windows 7 or maybe on XP? On XP there were no session-specific namespaces so maybe the error stands for this fact.

Sincerely yours
Eugene Mayevski
Posted: 08/01/2012 07:27:55
by Yves Roulet (Standard support level)
Joined: 01/12/2012
Posts: 9

I'm runnig on windows 7 ultimate
Posted: 08/01/2012 07:39:53
by Eugene Mayevski (EldoS Corp.)

Please try running the same code on some other computer and let me know the result. It is also possible that on VMWare session numbers for whatever reason are offset, so SESSION\2\ can be required. I can only guess at this point :(.

Sincerely yours
Eugene Mayevski
Posted: 08/01/2012 12:51:12
by Yves Roulet (Standard support level)
Joined: 01/12/2012
Posts: 9

Hi Eugene,

the problem is solved. If I put Session\1\ instead SESSION\1\ it's work fine. I's also true for Global\ instead GLOBAL\.

I check with sysinternal to see if the session are different with VM, but not they are equals as a single desktop.
Posted: 08/01/2012 13:08:37
by Eugene Mayevski (EldoS Corp.)

Very interesting. Thank you very much for posting - I was not careful enough to check casing (I believed the names are case-insensitive, as it happens with object names in NT, but this is not so with prefixes, as it turns out).

Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.



Topic viewed 6200 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!