So I started working on something using WMI... after writing a wrapper for some C++ examples I found in the WMI SDK and realized I jumped into the very deep side of the pool I figured Id better come here before I drown... but before I even bother posting a question... is there even anyone here who has itimate experiance working with WMI in an application?
WMI anyone?
- Thread starter bri189a
- Start date
PlausiblyDamp
Administrator
Not used it much myself but after see this post and the other one you posted (and fixed) I thought to ask if you are doing this via COM and C++ (seems to be the case)?
If so have you looked at the System.Management.Instrumentation namespace (you will need to add the appropriate reference)?
If so have you looked at the System.Management.Instrumentation namespace (you will need to add the appropriate reference)?
hmmm... not familiar with that one... but yes via COM and C# (but using C++ code examples... which is where I hit the brick wall)... the first function you have to use is CoInitializeEx which does something with threading because it throws the "Cannot change thread mode after it is set" error and threading operations is not my strong suit... 
Ill have to look and see what Instrumentation does.... thanks...
Ill have to look and see what Instrumentation does.... thanks...Just a quick glance it seems that my life may of just got a lot easier... didnt know about this one and everytime Ive searced for WMI in the IDE I always get references to the SDK so I didnt even know that was there... youre awesome... have you ever used these before?
PlausiblyDamp
Administrator
Never tried it at all - but Im not averse to having a play with it if you have any problems 
Ok Plaus - gotton pretty far with it an am really doing some cool things... heres the problem though, and it almost seems by design... I have a firewall running so I wouldnt of noticed this otherwise. You know how if you use Microsoft.Office.Excel incorrectly you get an Excel instance in your taskmanger that will remain there even after your done using it, and sometimes even worse, after you program is unloaded? Similiar thing, only its with the ports on your computer. Ive tried do the same thing that eliminates that Excel problem but there is not luck there, also cant seem to find anyone else who has noticed this... again it may be by design and then I wouldve of never noticed without my firewall. If you have a firewall yourself that you can monitor Id like to work with you on this... Ive grown frustrated at the Dispose() and GC.Collect() not doing actually destroying the references it appears (how else would these ports remain open?). And Ive tried several work around all to no avail... its probably something simple like the Excel is, its just a matter of figuring it out...
dynamic_sysop
Well-known member
have you tried the closesocket api? eg:
Code:
Declare Function closesocket Lib "ws2_32.dll" (ByVal s As Integer) As Integer
Dim Socket As Integer = " your open port here "
closesocket(Socket)Yes that would be an easy and great solution, however I have to be able to tell which sokets were opened by the app first....(as to not close sockets being used by other processes) do you know of an API that relates sockets used to its owner (program)? Thanks!
PlausiblyDamp
Administrator
http://www.sysinternals.com/ntw2k/source/tcpview.shtml, includes some c source as well.
Okay...let me rephrase that.... lol... I know which sockets are being used because my Firewall program lets me know... and C source code is something I dont really want to touch - Im a novice at C and C++; C# is my strong language; the problem is that the ports my program uses varies... and the IP address it connects to changes... so one execution of the code may be 138.56.118.41:108, the next execution of the program may be 138.56.118:109 - I have no control over that... System.Management does that for me... I guess what Im saying is these programs like the one you mentioned Plaus relates a port to a program; I need to do basically the same thing... and I guess Ill have to end up researching that... then shut the ports down myself... the whole point to the original post was that this is a managed set of classes that shouldnt act like this but they are and its frustrating me as to why?! Dispose should shut down the ports being used by that class... I shouldnt have to do the clean up work myself!
But to tell the truth the solution I am currently using works, as ugly as it may be. I have two EXEs basically... one is the main program, the second is a program that does the WMI stuff... The second program is a process that I start from the main program and is invisible so it only shows up in task manager, it does the work returns a completion code, then my main program (which is in the Process.WaitForCompletion state or whatever it is) gets focus back and based on that return process the information the other program created, this keeps my ports open only when they should be... its ugly... but it works. Ill look into how to detect ports that a program is using later or look at some examples... but right now as ugly as it may be, it works, Ill finese it later. Thanks!
But to tell the truth the solution I am currently using works, as ugly as it may be. I have two EXEs basically... one is the main program, the second is a program that does the WMI stuff... The second program is a process that I start from the main program and is invisible so it only shows up in task manager, it does the work returns a completion code, then my main program (which is in the Process.WaitForCompletion state or whatever it is) gets focus back and based on that return process the information the other program created, this keeps my ports open only when they should be... its ugly... but it works. Ill look into how to detect ports that a program is using later or look at some examples... but right now as ugly as it may be, it works, Ill finese it later. Thanks!
Last edited by a moderator: