It's about use of CreateIpcQueue() in Windows10.
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
I'm sorry. There was little information.
The one I'm testing now is 2.8.2.6 beta version.
It isn't official madCodeHook2.8.2.0.
I answer by this condition.
1) a memory leak problem exists. This is a cause of Microsoft. But release and re-generation of a IPC queue are being repeated. It's seen so as not to leak a memory seemingly by the thing.
2) The problem that the DestroyIpcQueue function stops occurs in official madCodeHook2.8.2.0. The IPC communication is always active. Release and re-generation of a IPC queue are repeated in an interval of once a second. Event probability is between 5000 times from 1000.
But even if I go 30,000 times by this 2.8.2.6 beta version, it doesn't occur.
3) a problem by the corrected DestroyIpcQueue function is being investigated by an aging test.
An error won't be reported from the function. But a message may not be sent to a generated IPC queue.
It was also reported a short while ago, but if it's a simple IPC communications program, it moves so that it may flow. So a possibility with the problem is high in the unnecessary processing I made.
It's high load throughout the day and I make them move, and it's confirmed whether it's no problem.
It'll be reported.
Thank you very much.
The one I'm testing now is 2.8.2.6 beta version.
It isn't official madCodeHook2.8.2.0.
I answer by this condition.
1) a memory leak problem exists. This is a cause of Microsoft. But release and re-generation of a IPC queue are being repeated. It's seen so as not to leak a memory seemingly by the thing.
2) The problem that the DestroyIpcQueue function stops occurs in official madCodeHook2.8.2.0. The IPC communication is always active. Release and re-generation of a IPC queue are repeated in an interval of once a second. Event probability is between 5000 times from 1000.
But even if I go 30,000 times by this 2.8.2.6 beta version, it doesn't occur.
3) a problem by the corrected DestroyIpcQueue function is being investigated by an aging test.
An error won't be reported from the function. But a message may not be sent to a generated IPC queue.
It was also reported a short while ago, but if it's a simple IPC communications program, it moves so that it may flow. So a possibility with the problem is high in the unnecessary processing I made.
It's high load throughout the day and I make them move, and it's confirmed whether it's no problem.
It'll be reported.
Thank you very much.
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
Hello, madshi.
A report, I'm sorry to be late.
A result of the aging test was seen. 2.8.2.6 beta version may leak a memory.
I looked for a problem.
I made an easy sample. madshi consulted a made sample.
The sample is sent to madshi by mail.
The code of a problem is as follows.
The CreateIpcQueue function and the DestroyIpcQueue function are being carried out and a IPC queue is being generated every 500 milliseconds.
This was compiled at official 2.8.2.0version and 2.8.2.6 beta version.
I made them move for 30 minutes, and both of them were compared. (I don't communicate from a client.)
Official 2.8.2.0 version is no problem.
2.8.2.6 beta version thinks a memory is leaked.
I think Heap leaks the result observed at ProcessExprorer and VMMap.
This screen shot is also sent by mail.
I want advice of madshi.
Thank you very much.
A report, I'm sorry to be late.
A result of the aging test was seen. 2.8.2.6 beta version may leak a memory.
I looked for a problem.
I made an easy sample. madshi consulted a made sample.
The sample is sent to madshi by mail.
The code of a problem is as follows.
Code: Select all
if (MessageBox(0, "Run as LPC Server?\n\nYES = LPC Server\nNO = LPC Client\n\nYou should always run the first instance as Server, and the 2nd as Client.", "question", MB_YESNO) == IDYES)
{
int i2;
b_que = CreateIpcQueue("TestSend1", (PIPC_CALLBACK_ROUTINE)&CB_TestSend1,0,1,4096 );
Sleep(500);
for(i2 = 0;i2 < 10000;i2++ ){
b_que = DestroyIpcQueue( "TestSend1" );
if( b_que != 0 ){
b_que = CreateIpcQueue("TestSend1", (PIPC_CALLBACK_ROUTINE)&CB_TestSend1,0,1,4096 );
if ( !b_que ) {
DispLog("[Error]NG CreateIpcQueue TestSend1 cht=%d",cx1_cnt);
}else{
cx1_cnt++;
}
}else{
DispLog( "[Error]NG DestroyIpcQueue TestSend1 cht=%d",cx1_cnt );
}
Sleep(500);
}
MessageBox(0, "Close this Window only after the Client has run through.\n\nPlease confirm the LPC leak by comparing the \"Virtual Size\" column in the Process Explorer for the LPC Server process, before vs after the Client has run.", "LPC Server", 0);
MessageBox(0, "The LPC port has been closed. Please check the \"Virtual Size\" column again to confirm that the leak was \"fixed\" by closing the LPC port.", "info", 0);
}
This was compiled at official 2.8.2.0version and 2.8.2.6 beta version.
I made them move for 30 minutes, and both of them were compared. (I don't communicate from a client.)
Official 2.8.2.0 version is no problem.
2.8.2.6 beta version thinks a memory is leaked.
I think Heap leaks the result observed at ProcessExprorer and VMMap.
This screen shot is also sent by mail.
I want advice of madshi.
Thank you very much.
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
Hello, madshi.
Has my opinion reached?
When there is information which isn't enough, I want you to tell me.
I cooperate with you.
Is this problem difficult?
If handle of a problem is impossible, I want you to tell me.
Thank you very much.
Has my opinion reached?
When there is information which isn't enough, I want you to tell me.
I cooperate with you.
Is this problem difficult?
If handle of a problem is impossible, I want you to tell me.
Thank you very much.
Re: It's about use of CreateIpcQueue() in Windows10.
I'm sorry for the late reply.
I've now tried to reproduce the problem, but on a quick check the problem doesn't seem to occur on my PC. I'm not 100% sure I've tested the right thing, though.
A few questions:
1) Are you using madCodeHook 3 or 4? I think you mentioned earlier you're using 4, is that correct?
2) Have you compiled your test EXEs as 32bit or 64bit? Did you try both? Does the problem occur in both bitdepths?
3) Did you use the static libs shipping with madCodeHook? Or did you recompile the madCodeHook source code yourself? If you recompiled the code, did you use the C++ or Delphi source code?
4) Does "VirtualSize" continue to grow if you keep the test projects running "forever"?
Have you heard anything back from Microsoft yet?
I've now tried to reproduce the problem, but on a quick check the problem doesn't seem to occur on my PC. I'm not 100% sure I've tested the right thing, though.
A few questions:
1) Are you using madCodeHook 3 or 4? I think you mentioned earlier you're using 4, is that correct?
2) Have you compiled your test EXEs as 32bit or 64bit? Did you try both? Does the problem occur in both bitdepths?
3) Did you use the static libs shipping with madCodeHook? Or did you recompile the madCodeHook source code yourself? If you recompiled the code, did you use the C++ or Delphi source code?
4) Does "VirtualSize" continue to grow if you keep the test projects running "forever"?
Have you heard anything back from Microsoft yet?
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
Thank you very much for your answer.
I answer your question.
1) madCodeHook uses 4.
2) 64Bit compilation was done. A build was performed in Visual Studio 2008. I'm not experimenting on 32bit.
The problem was confirmed in 64Bit.
3) I don't have source cord of madCodeHook.
So a static library is being used.
A library used the following.
http://madshi.net/madCollectionBeta.exe
(2.8.2.6 beta version)
4) VirtualSize keeps being increased by my environment.
A report was submitted to Microsoft from our staff.
The Microsoft side answered "Was this a security issue?"
But our side retorted "It wasn't a security issue. It was the bug!"
(It's like a gentleman.)
Two weeks will pass since it was reported. There are no answers from the MS side.
I have one doubt.
The character set of build setting of a project is changed, but is there a problem?
I make the character set MultiByte.
Original LPCBug sets Unicode.
In other words, I'm calling the CreateIpcQueue function and the DestroyIpcQueue function by "ANSI system".
Is it necessary to call this by "Wide system"?
If there is a problem, I want advice.
Thank you.
I answer your question.
1) madCodeHook uses 4.
2) 64Bit compilation was done. A build was performed in Visual Studio 2008. I'm not experimenting on 32bit.
The problem was confirmed in 64Bit.
3) I don't have source cord of madCodeHook.
So a static library is being used.
A library used the following.
http://madshi.net/madCollectionBeta.exe
(2.8.2.6 beta version)
4) VirtualSize keeps being increased by my environment.
A report was submitted to Microsoft from our staff.
The Microsoft side answered "Was this a security issue?"
But our side retorted "It wasn't a security issue. It was the bug!"
(It's like a gentleman.)
Two weeks will pass since it was reported. There are no answers from the MS side.
I have one doubt.
The character set of build setting of a project is changed, but is there a problem?
I make the character set MultiByte.
Original LPCBug sets Unicode.
In other words, I'm calling the CreateIpcQueue function and the DestroyIpcQueue function by "ANSI system".
Is it necessary to call this by "Wide system"?
If there is a problem, I want advice.
Thank you.
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
I experimented on "the ANSI system" and "Wide system".
A result was impartial.
Where is a memory also leaked?
It doesn't occur in madshi. It occurs by me.
I don't know whether you and I are partial.
There is a possibility that I make a mistake in me and am reporting it.
I call the memory leak I reported first "memory leak 1". I call the memory leak made a problem now "memory leak 2".
I know that "memory leak 1" is the bug of Microsoft.
"Memory leak 2" is the obstacle new and found in 2.8.2.6 beta version.
I'd like to put a problem in order once more.
Official 2.8.2.0 version:
Even if CreateIpcQueue function and DestroyIpcQueue function are carried out repeatedly, memory leak 2 doesn't occur.
When the SendIpcMessage function is carried out, memory leak 1 occurs.
When DestroyIpcQueue function is carried out, its memory leak 1 is canceled.
But DestroyIpcQueue function collides with the SendIpcMessage function. DestroyIpcQueue function suspends processing. A IPC queue can't be generated after that.
2.8.2.6 beta version:
When CreateIpcQueue function and DestroyIpcQueue function are carried out repeatedly, memory leak 2 occurs.
When the SendIpcMessage function is carried out, memory leak 1 occurs.
When DestroyIpcQueue function is carried out, its memory leak 1 is canceled.
DestroyIpcQueue function doesn't collide with the SendIpcMessage function. So memory leak 1 is canceled certainly.
2.8.2.6 beta version can cancel "memory leak 1" certainly.
But problems of "memory leak 2" occurs newly, and it can't be made a practical use of.
The problem which didn't occur in official 2.8.2.0 version. I think the difference in the correction parts is the cause of "memory leak 2".
Could you pay attention to this "memory leak 2"?
Would my idea be transmitted?
By long sentences, I'm sorry.
A result was impartial.
Where is a memory also leaked?
It doesn't occur in madshi. It occurs by me.
I don't know whether you and I are partial.
There is a possibility that I make a mistake in me and am reporting it.
I call the memory leak I reported first "memory leak 1". I call the memory leak made a problem now "memory leak 2".
I know that "memory leak 1" is the bug of Microsoft.
"Memory leak 2" is the obstacle new and found in 2.8.2.6 beta version.
I'd like to put a problem in order once more.
Official 2.8.2.0 version:
Even if CreateIpcQueue function and DestroyIpcQueue function are carried out repeatedly, memory leak 2 doesn't occur.
When the SendIpcMessage function is carried out, memory leak 1 occurs.
When DestroyIpcQueue function is carried out, its memory leak 1 is canceled.
But DestroyIpcQueue function collides with the SendIpcMessage function. DestroyIpcQueue function suspends processing. A IPC queue can't be generated after that.
2.8.2.6 beta version:
When CreateIpcQueue function and DestroyIpcQueue function are carried out repeatedly, memory leak 2 occurs.
When the SendIpcMessage function is carried out, memory leak 1 occurs.
When DestroyIpcQueue function is carried out, its memory leak 1 is canceled.
DestroyIpcQueue function doesn't collide with the SendIpcMessage function. So memory leak 1 is canceled certainly.
2.8.2.6 beta version can cancel "memory leak 1" certainly.
But problems of "memory leak 2" occurs newly, and it can't be made a practical use of.
The problem which didn't occur in official 2.8.2.0 version. I think the difference in the correction parts is the cause of "memory leak 2".
Could you pay attention to this "memory leak 2"?
Would my idea be transmitted?
By long sentences, I'm sorry.
Re: It's about use of CreateIpcQueue() in Windows10.
Here's a new test build:
http://madshi.net/madCollectionBeta.exe (installer 2.8.2.9)
The new memory leak should be fixed. I'm not completely sure if the freeze/stall problem with DestroyIpcQueue is still fixed, it might have come back, but I hope not. Could you please double check and let me know? Thanks!
http://madshi.net/madCollectionBeta.exe (installer 2.8.2.9)
The new memory leak should be fixed. I'm not completely sure if the freeze/stall problem with DestroyIpcQueue is still fixed, it might have come back, but I hope not. Could you please double check and let me know? Thanks!
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
I was waiting! madshi.
I'm very thankful!
It'll be tested right away.
When it's possible, I make a news flash on!
There is business of the company, so this weekend can't be reported.
But a result will be reported early next week. My, as much as possible.
Thank you very much!
I'm very thankful!
It'll be tested right away.
When it's possible, I make a news flash on!
There is business of the company, so this weekend can't be reported.
But a result will be reported early next week. My, as much as possible.
Thank you very much!
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
A newsletter of a test.
A result looks good.
It was every 500 milliseconds and CreateIpcQueue function and DestroyIpcQueue function were carried out.
It's every 500 milliseconds using SendIpcMessage function, and a message is sent to the IPC queue from a different process.
That was repeated for 3 hours.
"Memory leak 2" which I called doesn't occur.
DestroyIpcQueue function isn't stopped.
But SendIpcMessage function suspended it.
I think the cause is the following sixth parameter.
answerTimeOut : dword = INFINITE;
I thought I was waiting for the IPC queue which became extinct all the while.
So this was set as 1000 milliseconds from -1.
SendIpcMessage function isn't also stopped by this measure.
I think consequently, the next code should be written by 2.8.2.9 versions.
I think the IPC communication 240 byte bug of MicroSoft can be avoided with this.
I'll enter an aging test now.
A result will be reported in the beginning of the next week.
Thank you very much, Madshi.
A result looks good.
It was every 500 milliseconds and CreateIpcQueue function and DestroyIpcQueue function were carried out.
It's every 500 milliseconds using SendIpcMessage function, and a message is sent to the IPC queue from a different process.
That was repeated for 3 hours.
"Memory leak 2" which I called doesn't occur.
DestroyIpcQueue function isn't stopped.
But SendIpcMessage function suspended it.
I think the cause is the following sixth parameter.
answerTimeOut : dword = INFINITE;
I thought I was waiting for the IPC queue which became extinct all the while.
So this was set as 1000 milliseconds from -1.
SendIpcMessage function isn't also stopped by this measure.
I think consequently, the next code should be written by 2.8.2.9 versions.
I think the IPC communication 240 byte bug of MicroSoft can be avoided with this.
Code: Select all
[Server Side]
#define QueRenewInterval 60
int Devctl_DVCStatType_1_cnt;
int Devctl_DVCStatType_2_cnt;
Devctl_DVCStatType_1_cnt = QueRenewInterval;
Devctl_DVCStatType_2_cnt = QueRenewInterval * 2;
//Interrupt every one second
case WM_TIMER:
if( Devctl_DVCStatType_1_cnt <= 0 ){
b_que = DestroyIpcQueue( "Devctl_DVCSendType-1" );
if( b_que == 0 ){
b_que = CreateIpcQueue("Devctl_DVCSendType-1", (PIPC_CALLBACK_ROUTINE)&CB_Devctl_DVCSendType,0,1,4096 );
if ( !b_que ) {
DispLog("[Error]");
}else{
Devctl_DVCStatType_1_cnt = QueRenewInterval * 2;
}
}
}else{
Devctl_DVCStatType_1_cnt--;
}
//----------
if( Devctl_DVCStatType_2_cnt <= 0 ){
b_que = DestroyIpcQueue( "Devctl_DVCSendType-2" );
if( b_que == 0 ){
b_que = CreateIpcQueue("Devctl_DVCSendType-2", (PIPC_CALLBACK_ROUTINE)&CB_Devctl_DVCSendType,0,1,4096 );
if ( !b_que ) {
DispLog("[Error]");
}else{
Devctl_DVCStatType_2_cnt = QueRenewInterval * 2;
}
}
}else{
Devctl_DVCStatType_2_cnt--;
}
[Injection DLL Side]
strcpy( quename1,"Devctl_DVCSendType-1" );
strcpy( quename2,"Devctl_DVCSendType-2" );
res = SendIpcMessage( quename1
,Buffer,BufLen,resbuf,resvallen,5000,SIPCM_hmMode);
if( res == 0 ){
res = SendIpcMessage( quename2
,Buffer,BufLen,resbuf,resvallen,5000,SIPCM_hmMode);
}
I'll enter an aging test now.
A result will be reported in the beginning of the next week.
Thank you very much, Madshi.
Re: It's about use of CreateIpcQueue() in Windows10.
Sounds promising so far! ![smile :)](./images/smilies/icon_razz.gif)
![smile :)](./images/smilies/icon_razz.gif)
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
Hello, Madshi.
A result of the aging test will be reported.
Re-generation of the IPC queue for which the CreateIpcQueue function and the DestroyIpcQueue function were used doesn't generate memory leak.
The DestroyIpcQueue function doesn't stop.
Communication by the SendIpcMessage function isn't suspended.
(It's subject to the restrictions which make the sixth parameter all except for -1.)
The SendIpcMessage function returns false in case of a communication error.
When communication is normal, true is returned.
I think IPC communication is performed.
This is the result which made the next code work continuously for 3 days.
This code is every 500 milliseconds and does re-generation of a IPC queue. It's every 500 milliseconds and IPC communication is performed.
But there is one strange result.
I want you to see the next log.
This is an output of the DispLog function in the code.
I wait for at most 1500 milliseconds to the SendIpcMessage function of the once by my cord.
The beginning is log as expected.
(2017-7-6 17:20:41)
But "the SendIpcMessage function is waiting after that for 5 seconds extra", seem.
Even if the SendIpcMessage function succeeds, it's always every 6 seconds and it's processed. Even if I fail, the function is every 6 seconds, and it's processed.
(I think the SendIpcMessage function is doing time-out certainly.)
All others are normal, but this point isn't understood.
I want advice of Madshi about the SendIpcMessage function.
Thank you very much.
A result of the aging test will be reported.
Re-generation of the IPC queue for which the CreateIpcQueue function and the DestroyIpcQueue function were used doesn't generate memory leak.
The DestroyIpcQueue function doesn't stop.
Communication by the SendIpcMessage function isn't suspended.
(It's subject to the restrictions which make the sixth parameter all except for -1.)
The SendIpcMessage function returns false in case of a communication error.
When communication is normal, true is returned.
I think IPC communication is performed.
This is the result which made the next code work continuously for 3 days.
This code is every 500 milliseconds and does re-generation of a IPC queue. It's every 500 milliseconds and IPC communication is performed.
Code: Select all
void WINAPI CB_TestSend1(
LPCSTR pIpc,
LPCVOID pMessageBuf,
DWORD dwMessageLen,
LPVOID pAnswerBuf,
DWORD dwAnswerLen,
LPVOID pContext
)
{
unsigned char c;
c = 0x0;
int i;
for( i = 0;i < 256;i++ ){
c = c ^ *((char *)pMessageBuf + i);
}
*((char *)pAnswerBuf) = c;
//DispLog( "CB_ANS=%x",c );
return;
}
int __stdcall WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
int b_que;
int cx1_cnt = 0;
int res;
SetCurrentPath();
//
int j;
unsigned char c;
c = 0x0;
for( j = 0;j < 0;j++ ){
sendbuf[j] = c;
c++;
}
if (MessageBox(0, "Run as LPC Server?\n\nYES = LPC Server\nNO = LPC Client\n\nYou should always run the first instance as Server, and the 2nd as Client.", "question", MB_YESNO) == IDYES)
{
int i2;
b_que = CreateIpcQueue( "TestSend1", (PIPC_CALLBACK_ROUTINE)&CB_TestSend1,0,1,4096 );
Sleep(500);
for(i2 = 0;i2 < 1000000;i2++ ){
b_que = DestroyIpcQueue( "TestSend1" );
if( b_que != 0 ){
//DispLog( "TestSend1 start" );
b_que = CreateIpcQueue( "TestSend1", (PIPC_CALLBACK_ROUTINE)&CB_TestSend1,0,1,4096 );
//DispLog( "CreateIpcQueue-1 end = %d", b_que );
if ( !b_que ) {
DispLog("[Error]NG CreateIpcQueue TestSend1 cht=%d",cx1_cnt);
}else{
cx1_cnt++;
}
}else{
DispLog( "[Error]NG DestroyIpcQueue TestSend1 cht=%d",cx1_cnt );
}
Sleep(500);
}
//HANDLE ipcPort = CreateLpcQueue();
MessageBox(0, "Close this Window only after the Client has run through.\n\nPlease confirm the LPC leak by comparing the \"Virtual Size\" column in the Process Explorer for the LPC Server process, before vs after the Client has run.", "LPC Server", 0);
// closing the port gets rid of all the leaks
//CloseHandle(ipcPort);
MessageBox(0, "The LPC port has been closed. Please check the \"Virtual Size\" column again to confirm that the leak was \"fixed\" by closing the LPC port.", "info", 0);
}
else
{
unsigned char resbuf[16];
DWORD reslen;
for (int i1 = 0; i1 < 1000000; i1++){
reslen = 16;
//
resbuf[0] = 0xff;
res = SendIpcMessage( "TestSend1"
,sendbuf,256,resbuf,reslen,1000,true );
c = *((char *)resbuf);
DispLog( "SendIpcMessage Res=%d",res );
if( c != 0x0 ){
DispLog( "SendIpcMessage ResultError=%x cnt=%d",c,i1 );
}
Sleep(500);
}
MessageBox(0, "The LPC Client has run through.", "info", 0);
}
return 0;
}
But there is one strange result.
I want you to see the next log.
This is an output of the DispLog function in the code.
Code: Select all
2017-7-6 17:20:18 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:18 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:19 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:19 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:20 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:21 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:21 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:22 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:22 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:23 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:23 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:24 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:24 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:25 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:25 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:26 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:26 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:27 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:27 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1536
2017-7-6 17:20:27 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:27 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1537
2017-7-6 17:20:28 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:28 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1538
2017-7-6 17:20:28 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:28 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1539
2017-7-6 17:20:29 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:29 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1540
2017-7-6 17:20:29 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:30 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:30 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1542
2017-7-6 17:20:30 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:30 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1543
2017-7-6 17:20:31 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:31 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1544
2017-7-6 17:20:31 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:31 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1545
2017-7-6 17:20:32 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:33 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:33 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1547
2017-7-6 17:20:33 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:34 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:34 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1549
2017-7-6 17:20:34 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:34 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1550
2017-7-6 17:20:35 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:20:41 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1551
2017-7-6 17:20:47 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:20:54 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:1 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:7 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:14 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:20 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:27 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:34 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:40 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:47 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:21:54 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:0 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:7 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:14 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:20 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:27 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:34 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:40 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:47 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:22:53 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:0 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:7 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:13 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:20 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:27 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:33 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:40 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:46 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:23:53 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:24:0 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:24:6 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:24:13 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:24:20 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:24:26 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1584
2017-7-6 17:24:32 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:24:39 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:24:45 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:24:52 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:24:59 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:25:5 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:25:12 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:25:18 [16f8:9bc] SendIpcMessage Res=1
2017-7-6 17:25:25 [16f8:9bc] SendIpcMessage Res=0
2017-7-6 17:25:31 [16f8:9bc] SendIpcMessage ResultError=ff cnt=1593
2017-7-6 17:25:38 [16f8:9bc] SendIpcMessage Res=1
I wait for at most 1500 milliseconds to the SendIpcMessage function of the once by my cord.
The beginning is log as expected.
(2017-7-6 17:20:41)
But "the SendIpcMessage function is waiting after that for 5 seconds extra", seem.
Even if the SendIpcMessage function succeeds, it's always every 6 seconds and it's processed. Even if I fail, the function is every 6 seconds, and it's processed.
(I think the SendIpcMessage function is doing time-out certainly.)
All others are normal, but this point isn't understood.
I want advice of Madshi about the SendIpcMessage function.
Thank you very much.
Re: It's about use of CreateIpcQueue() in Windows10.
Server side:
1) The IPC server receives your IPC message.
2) Your IPC request in stored in an internal queue.
3) Event 1 is set.
4) Some worker thread then calls your IPC callback function.
5) After your callback function returns, Event 2 is set.
Client side:
1) An LPC port is opened and connected.
2) Code is waiting for Event 1.
3) Code is waiting for Event 2.
There are 2 different Events because the first Event should always fire (almost) immediately. The 2nd Event is fired only after your IPC callback function has returned. In theory your IPC callback function could use MessageBox(), so it could be "stuck" for seconds or even minutes/hours.
The wait for Event 1 is using an internal timeout value. The "timeout" value you can set as part of the SendIpcMessage() call only applies to the waiting for Event 2. The internal timeout value for Event 1 defaults to 7 seconds. You can change this timeout value by using "SetMadCHookOption(SET_INTERNAL_IPC_TIMEOUT, (LPWSTR) timeoutValueForEvent1)". More details here:
http://help.madshi.net/mchOptions.htm
I'm not sure, maybe this design with 2 different timeout values is confusing? I suppose if your SendIpcMessage timeout parameters is smaller than the "internal timeout" value, then I should probably also automatically lower the "internal timeout" for this IPC message to the same value?
1) The IPC server receives your IPC message.
2) Your IPC request in stored in an internal queue.
3) Event 1 is set.
4) Some worker thread then calls your IPC callback function.
5) After your callback function returns, Event 2 is set.
Client side:
1) An LPC port is opened and connected.
2) Code is waiting for Event 1.
3) Code is waiting for Event 2.
There are 2 different Events because the first Event should always fire (almost) immediately. The 2nd Event is fired only after your IPC callback function has returned. In theory your IPC callback function could use MessageBox(), so it could be "stuck" for seconds or even minutes/hours.
The wait for Event 1 is using an internal timeout value. The "timeout" value you can set as part of the SendIpcMessage() call only applies to the waiting for Event 2. The internal timeout value for Event 1 defaults to 7 seconds. You can change this timeout value by using "SetMadCHookOption(SET_INTERNAL_IPC_TIMEOUT, (LPWSTR) timeoutValueForEvent1)". More details here:
http://help.madshi.net/mchOptions.htm
I'm not sure, maybe this design with 2 different timeout values is confusing? I suppose if your SendIpcMessage timeout parameters is smaller than the "internal timeout" value, then I should probably also automatically lower the "internal timeout" for this IPC message to the same value?
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
Thank you very much for your answer.
Your idea was understood.
(I think it was probably understood.)
My experimental result is checked with the explanation of madshi.
I think, don't turn back if "stuck" is done in Event1.
That starts to wait for time designated in SET_INTERNAL_IPC_TIMEOUT certainly.
It's impossible to generate "stuck" sooner or later and evade that.
Is the understanding right?
In that case it's necessary to make value designated in SET_INTERNAL_IPC_TIMEOUT small value.
For example" SetMadCHookOption (SET_INTERNAL_IPC_TIMEOUT,L"500");"
When the big vaule is established, time to wait wastefully at "stuck" just increases.
When making it small Value, to return an error would be here.
Still when returning an error, I can handle.
I make an experiment.
It'll be reported.
Thank you very much.
Your idea was understood.
(I think it was probably understood.)
My experimental result is checked with the explanation of madshi.
I think, don't turn back if "stuck" is done in Event1.
That starts to wait for time designated in SET_INTERNAL_IPC_TIMEOUT certainly.
It's impossible to generate "stuck" sooner or later and evade that.
Is the understanding right?
In that case it's necessary to make value designated in SET_INTERNAL_IPC_TIMEOUT small value.
For example" SetMadCHookOption (SET_INTERNAL_IPC_TIMEOUT,L"500");"
When the big vaule is established, time to wait wastefully at "stuck" just increases.
When making it small Value, to return an error would be here.
Still when returning an error, I can handle.
I make an experiment.
It'll be reported.
Thank you very much.
-
- Posts: 32
- Joined: Fri May 12, 2017 5:14 am
Re: It's about use of CreateIpcQueue() in Windows10.
Hello, madshi.
I thought I reported an experimental result.
But a very strange phenomenon occurs.
Microsoft seems to have corrected the bug.
I applied WindowsUpdate on July 12 in Japan.
Even if I make a test program move, a phenomenon of memory leak doesn't occur.
Perhaps I think memory leak doesn't also occur any more in the other countries.
I think that I'd like this, but I'm sorry and think at the same time.
Madshi worked well.
madshi asked my opinion. He was sincere. I'm really thankful.
To be honest, I didn't think Microsoft corrected the bug.
I lost all my strength. I'm careful of the way home.
Thank you for associating with Madshi for a long time.
I thank you much. But I think it isn't enough. Thank you very much really.
I thought I reported an experimental result.
But a very strange phenomenon occurs.
Microsoft seems to have corrected the bug.
I applied WindowsUpdate on July 12 in Japan.
Even if I make a test program move, a phenomenon of memory leak doesn't occur.
Perhaps I think memory leak doesn't also occur any more in the other countries.
I think that I'd like this, but I'm sorry and think at the same time.
Madshi worked well.
madshi asked my opinion. He was sincere. I'm really thankful.
To be honest, I didn't think Microsoft corrected the bug.
I lost all my strength. I'm careful of the way home.
Thank you for associating with Madshi for a long time.
I thank you much. But I think it isn't enough. Thank you very much really.
Re: It's about use of CreateIpcQueue() in Windows10.
I've just run Microsoft Update and installed the latest updates offered to me, which included July cumulative update. But the IPC leak problem still exists on my PC! I'm still on build 15063, though. Maybe it's fixed in the latest Windows 10 RS3 test build? I don't know.
In any case, we worked together to make DestroyIpcQueue() better. It now always works without freezes and without memory leaks, which is a nice improvement! So even if Microsoft now fixes the IPC leak bug, we still improved madCodeHook, which I'm happy about.
So thanks for reporting the problem(s), and your help with testing the changes/improvements!
In any case, we worked together to make DestroyIpcQueue() better. It now always works without freezes and without memory leaks, which is a nice improvement! So even if Microsoft now fixes the IPC leak bug, we still improved madCodeHook, which I'm happy about.
So thanks for reporting the problem(s), and your help with testing the changes/improvements!