Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
Memory increase by using WMI Service
It is something that is beyond our control and therefore, unfortunately, we cannot offer you any more help in this respect, at least until some new information appears that would "unblock" the investigation.
In our application the getnetwork is in a seperate thread.
I have change the the test project2 to project3 in set the getnetwork in a thread !
The same problem !!
Here the test Project "Project3.exe"
You can test it on your own PC !
We can not use the second way, because it make our application to slow ! We have serial connection that must run in all 100 ms !
This would be more for Microsoft to explain what they are doing. To me, it looks related to a fact that a COM thread in a single-threaded apartment (STA) must do Windows message pumping for COM to work properly, and possibly the /NET CLR is somehow mixing it up. But that is a hypothesis again.
I found two ways of preventing the problem:
1. Do not use Delphi TTimer to invoke COM-related code such as GetNetworks. Instead, use a thread with a loop and some "sleep" - the same way as you are already doing in your code for other periodic tasks.
2. Add message pumping to the code invoked by the TTimer. Basically, besides doing the work you want to do (GetNetworks, for example), try to pump messages every time the timer procedure is invoked. The procedure below is an example of doing that.
uses IdGlobal, Messages, Windows; procedure PumpSleep(MiliSecValue : cardinal); var Dummy: DWord; EndTick: Cardinal; Msg: TMsg; StartTick: Cardinal; Timeout: Int64; begin // Pump messages in order to receive COM events. Not needed in VCL Forms. StartTick := Ticks; EndTick := StartTick + MiliSecValue; repeat Timeout := EndTick - Ticks; if Timeout <= 0 then Break; if MsgWaitForMultipleObjects(0, Dummy, False, Timeout, QS_ALLINPUT) = 0 then begin if GetMessage(Msg, 0, 0, 0) then begin if Msg.Message = WM_QUIT then Halt; TranslateMessage(Msg); DispatchMessage(Msg); end; end; until False; end;
I am able to reproduce what appears as unlimited memory increase when I press both the "Start Thread Reader" and "Read cyclic WMI Network inactiv" buttons. I will investigate it. It could be that something is preventing the .NET garbage collector from running.
When I read a wrong (or good) node without Network adapter scan, I see no memory increase.
We use the code in "Read Cyclic WMI Network activ" in our application ! This code do not increase the memory !
Both procedure do not increase the memory if it run single !
It is in combined with the "Start Thread Reader" !
I dont know wich part increase the memory ?
Can you see wich part increase the memory ?
Do you get a memory increase if you do *not* press that button?
- Reimported the type libraries.
- Removed the "Sleep(10)" line in the read cycle, in order for it to work and consume memory much faster.
- Changed the endpoint and node to our server, so that the read succeeds.
- Rebuilt the project.
- Ran it, pressed "Start Thread Reader".
I am not sure if I have to do something else too.