It's about use of CreateIpcQueue() in Windows10.

[icckitagawa]

Hello, madshi.

Thank you very much for your answer.

It was understood because there was change in nativeAPIs on the WindowsOS side.


Presentation is the plan to avoid which was here, but let me question with that, please.

I duplicated a IPC queue on May 19 and made the experiment which opens a IPC queue with release periodically.
You could fail in closure of a IPC queue by about 5000 times by my experiment and never open it after that.


I used DestroyIpcQueue. But when it's carried out several times, processing isn't returned any more.
When a plan to avoid of madshi is seen, it's in the item of the 3) with call "CloseHandle (IpcPortHandle)".


A IPC queue is opened in CreateIpcQueue, and is this that it should close in CloseHandle (IpcPortHandle)?
When this is right, please tell me how to look for it IpcPortHandle which gives it to CloseHandle.
I think so as not to return its price by the CreateIpcQueue function.

When you'd tell someone, you can prove whether this idea is right by the experimental program I made before.

Thank you very much.

[madshi]

Does the problem with DestroyIpcQueue() only occur if IPC messages are sent? Or does it also occur if no IPC messages are sent at all?

[icckitagawa]

About the problem that the DestroyIpcQueue function doesn't return processing any more.
I'm not testing the case to which a IPC message isn't sent.
This is because it's test case which isn't needed for me.

With not doing the SendIpcMessage function at all from the InjectDLL side, I can do the test which carries out the DestroyIpcQueue function and the CreateIpcQueue function continuously.
But even if a problem of DestroyIpcQueue settles it with that, I think it's unprofitable for us.


If it's significant, I would be happy to help to work. As far as it's possible again, information is offered.
When not sending a IPC message, the test is possible, but is this test significant?

The one by which madshi did this question or I can't grasp the meaning.

I'm sorry.

[icckitagawa]

Hello, madshi.

I thought it was significant for you to question.

You pointed out, "When IPC communication isn't done at all.", a movement test of the DestroyIpcQueue function was performed.


The result is interesting.

Even if closure of a IPC queue and re-generation are performed 20,000 times by the same process, failures don't occur.
The DestroyIpcQueue function normally keeps moving.

I was thinking it was insignificant in this result, but it's different now.

The DestroyIpcQueue function thinks it itself is right.

I think it's to say "You aren't supposed to call the DestroyIpcQueue function during IPC communication." Is it so?
In that case would there be a way to close a IPC queue "with no problem" during IPC communication?

I'd like to ask for your advice.


Thank you very much.

[madshi]

Hello,

thanks for doing that test. I'll try to reproduce the freeze when calling DestroyIpcQueue during active IPC communication here. Maybe I can find around the issue.

You can't limit the IPC message size to 240 bytes?

[icckitagawa]

Hello, madshi.

A test is being also continued now. 40000 times are exceeded already.
The DestroyIpcQueue function was called, but it's just normal.

Your idea can't be understood, and I think it was bad. I'm sorry.


It's the proposition that the size of the IPC message is restricted to 240 bytes, but it's difficult at present.
My system is telling file access of each process by IPC communication.
This consists of at least 600 bytes and check-sum including other status.
More than 600 bytes are being sent by 1 of IPC communication. Division has to send this to about 200 bytes.
I'd like to avoid substantial remodeling of a communication module by this and a decline of the throughput.
(The communication amount is same and the IPC number of times becomes triple, so, an overhead becomes a lot.)


When you can't settle a DestroyIpcQueue problem, I think it'll be to restrict it 240 bytes.
Your advice is needed in that case.
When being hard to see, please tell me as soon as possible.


An answer of madshi was tested even here.
As your comment, this doesn't also generate memory leak by 240 bytes.
A problem occurs from 241 bytes.
This experimented on IPC communication of Windows10-32bit, 64bit and 32bit on WOW64, but all rules are applied 240 bytes.
madshi is working well.

Thank you very much.

[madshi]

I wish I had a Microsoft contact to report the > 240 byte bug to, but I don't.

I'll try to find a solution for the DestroyIpcQueue freeze problem.

[madshi]

Here's a test project which reproduces the problem, so you can send it to Microsoft for getting it fixed:

http://madshi.net/LpcBug.zip

It's possible that Microsoft will refuse to investigate because the test project is using "undocumented" LPC APIs. However, these APIs are used by the OS internally *a lot*. So I believe it should be worth it for them to investigate, because I believe there's a serious bug in Windows 10.

[madshi]

Ok, and here's a new test build which has a slightly changed DestroyIpcQueue() routine. Can you please double check if this build is able to reliably close the IPC queue even during active IPC traffic?

http://madshi.net/madCollectionBeta.exe (installer 2.8.2.6)

[icckitagawa]

Thank you very much, madshi!

Right away, I'll try a beta module and confirm the problem of the DestroyIpcQueue function.
Please wait for one day. It's examined whether a problem doesn't occur.


A API sample of a problem is also sent to the tapir report desk of Microsoft.

I'd like to be thankful for in haste and you! Thank you very much!

After trying beta for more information, it's told.

Thank you very much.

[icckitagawa]

Hello, madshi.

I'm estimating about "2.8.2.6 beta" an offer matches.

It's being tested from Windows10-32bit at present.
It's a newsletter, but the movement is strange.

A test, a second, a IPC queue, I become extinct and am repeating re-generation.

The DestroyIpcQueue function looks normal.
It's normally ended even in the active IPC traffic.
I don't say that processing isn't returned like before.

But when making a queue with the CreateIpcQueue function once again, the function succeeds in return value -1, actually, IPC, you don't seem to communicate, it'll be.
While this is 5000 times from 1000, when re-generation of a IPC queue is repeated, it occurs.
Once it was in this state, IPC communication doesn't succeed again.
(Even if it'll be so, the DestroyIpcQueue function and the CreateIpcQueue function return a normal return value.)


The test condition is near torture.
It's necessary to leave the re-generation space of a IPC queue more and when there is advice, I want.

Thank you very much.

[madshi]

Hmmm... The translator you're using isn't doing a very good job, I'm not sure I fully understand what you're saying.

Would it be difficult for you to create a little project with which I could reproduce the problem you're describing?

[icckitagawa]

Hello, madshi.


My explanation is incomprehensible. I'm sorry.

Your opinion is reasonable.
I make the short sample a problem generates.
That's handed to you as soon as possible.

Please wait for several days.

Thank you very much.

[icckitagawa]

Hello, madshi.


Maybe I was wrong.


A small sample was made your purpose.
If it's carried out on probation, that moves excellently!

It looks perfect about the CreateIpcQueue function, the DestroyIpcQueue function and the SendIpcMessage function.

While a IPC queue is Re-generating the SendIpcMessage function, it returns as an error neatly.

Nothing stops and communication isn't also lost! They don't also seem to be doing memory leak up to now.


I thought. What was bad?
When the DestroyIpcQueue function stopped, my module was being had and thread-ized.
The playing cheap tricks seems to have been bad.

If it's rewritten simply, I have begun to move so that it may flow!
The former movement seems to be a bullfinch.


A weekend aging test is performed, and makes sure whether it's no problem.
I want you to make them report a result.

madshi is your favor. Thank you very much really.

[madshi]

Hmmmm... I'm not sure I understand. Please allow me to ask:

1) You reported the memory leak problem, which I was able to reproduce. This problem is still there, or is it not?

2) You reported that DestroyIpcQueue could get stuck, which I was able to reproduce. This problem is still there with the official madCodeHook version, or is it not?

3) You reported that the test build with a modified DestroyIpcQueue made some new problems. I didn't fully understand which problems you experienced.

Can you please say which of these 3 problems exist in the official madCodeHook build, and which exist in the test build with the modified DestroyIpcQueue version?

Thanks!