Ok, this is a scheme that shows my project

Process A : Creates a file-mapping empty (with no file in it) in order to be
used as a shared memory, then it creates a mutex ; both the operations have
controls to check their correct working.
Both the structure (file-mapping and mutex) have got a name, in order to be
opened by other processes, the mutex name is mtx and the filemapping name is
my_mapping.

Process B : Opens the file-mapping genereated in A by OpenFileMapping
instruction (using my_mapping name), attaches it to the memory of the
process by MapViewOfFile and gets the address of this attach.
Then it opens the Mutex (using mtx name). Both the operations have controls
to check their correct working.
Now the function of B is to allow users to manage a collection of messages
written in the shared memory installed before. It is made with 3 different
operations :
Add : adds a new message in queue to the other messages (if there is enough
space, due to collection-limits)
Remove : removes the last message in the shared memory (the last message put
in memory)
View : views all the messages in the shared memory.

Now the use of a mutex is necessary to avoid data-inconsistence : if 2 users
work on the program, they can use add function at the same time so that both
writes in the same position of memory, so that it will contain only the
informations of the last who wrote on the memory, giving data-inconsistence.
So if one wants to use those functions, immediately before the access to
shared memory there is a WaitForSingleObject on the mutex, and immediately
after the end of the operations there is a ReleaseMutex.

The problem is this : sometimes even if only one single user uses the
program function like add-remove, the program blocks as if there was some
other user working on shared memory (as if the mutex is working improperly),
and there is no way to unblock it but closing the window and restarting both
the A-B processes.
This fact happens casually, not if I do a precise procedure or activate
something.
Maybe, according to me, the cause is in the desidered mode of access to the
mutex specified in the OpenMutex operation : msdn says to use
MUTEX_MODIFY_STATE if ReleaseMutex function is needed (as in my case)
using this choose, I obtain this : the program never blocks, but the mutex
does not work (If I open 2 instances, the first is doing "add", and do "add"
also in the second, the second is not blocked by the mutex as it should be!)
if I use MUTEX_ALL_ACCESSES I obtain the situation I've described.

I've also thought it can depend on de boolean regulating the inherit rights
of the mutex, (in my case is set on FALSE).

I write now an explicative part of the code (Written in C language with
<windows.h> library)

PROCESS A:
#include <windows.h>
#define errore(a) {printf(a);ExitProcess(2);}
HANDLE shmem1,sem1;

int main(int argc, char *argv[]) {
shmem1 =
CreateFileMapping(INVALID_HANDLE_VALUE,NULL,PAGE_READWRITE,0,500000,"my_mapp
ing");
if (shmem1 == NULL) errore("Error : Creating ShMem!\n");
printf("ShMem Installed!\n");

sem1 = CreateMutex(0,FALSE,"mtx");
if (sem1==NULL) errore("Errore : Creating Mutex");
printf("Mutex Installed!\n");

}

PROCESS B:
#include <windows.h>
#define errore(a) {printf(a);ExitProcess(2);}

HANDLE shmem,sem; char *attach;

void add/remove/view() {<FUNCTION CODE>;
WaitForSingleObject(mtx,INFINITE);
<OPERATIONS ON SHARED MEMORY>;
ReleaseMutex(sem);
}

void console() {<ALLOWS THE USER TO SELECT  THE FUNCTIONS, AFTER THE
FUNCTION IT IS RELOADED UNTIL USER CHOOSES FOR "quit">

int main (int argc, char *argv[]) {

shmem = OpenFileMapping(FILE_MAP_ALL_ACCESS,TRUE,"my_mapping");
if (shmem == NULL) errore("Error : Opening ShMem!\n");
printf("ShMem Opened!\n");

attach =(char*)MapViewOfFile(shmem,FILE_MAP_WRITE,0,0,0);

if (attacco == NULL) errore("Error : attaching ShMem to memory process!\n");
printf("ShMem Attached to memory process!\n");

sem = OpenMutex(MUTEX_ALL_ACCESS,FALSE,"mtx");
if (sem==NULL) errore("Error : Opening Mutex!\n");
printf("Mutex Opened!\n");

<LAUNCH CONSOLE> --do until "quit"--

ExitProcess(0);}

NB : First I execute A, then I execute B (while A is still working)

Thank you again!!!!!!
Leonardo