bri189a Posted January 5, 2004 Posted January 5, 2004 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 I'd 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? Quote
Administrators PlausiblyDamp Posted January 5, 2004 Administrators Posted January 5, 2004 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)? Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
bri189a Posted January 5, 2004 Author Posted January 5, 2004 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... :( I'll have to look and see what Instrumentation does.... thanks... Quote
bri189a Posted January 5, 2004 Author Posted January 5, 2004 Just a quick glance it seems that my life may of just got a lot easier... didn't know about this one and everytime I've searced for WMI in the IDE I always get references to the SDK so I didn't even know that was there... you're awesome... have you ever used these before? Quote
Administrators PlausiblyDamp Posted January 6, 2004 Administrators Posted January 6, 2004 Never tried it at all - but I'm not averse to having a play with it if you have any problems ;) Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
bri189a Posted January 26, 2004 Author Posted January 26, 2004 Ok Plaus - gotton pretty far with it an am really doing some cool things... here's the problem though, and it almost seems by design... I have a firewall running so I wouldn't 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 it's with the ports on your computer. I've tried do the same thing that eliminates that Excel problem but there is not luck there, also can't seem to find anyone else who has noticed this... again it may be by design and then I would've of never noticed without my firewall. If you have a firewall yourself that you can monitor I'd like to work with you on this... I've grown frustrated at the Dispose() and GC.Collect() not doing actually destroying the references it appears (how else would these ports remain open?). And I've tried several work around all to no avail... it's probably something simple like the Excel is, it's just a matter of figuring it out... Quote
Leaders dynamic_sysop Posted January 27, 2004 Leaders Posted January 27, 2004 have you tried the closesocket api? eg: Declare Function closesocket Lib "ws2_32.dll" (ByVal s As Integer) As Integer Dim Socket As Integer = " your open port here " closesocket(Socket) Quote
bri189a Posted January 29, 2004 Author Posted January 29, 2004 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 it's owner (program)? Thanks! Quote
Administrators PlausiblyDamp Posted January 29, 2004 Administrators Posted January 29, 2004 http://www.sysinternals.com/ntw2k/source/tcpview.shtml, includes some c source as well. Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
bri189a Posted January 29, 2004 Author Posted January 29, 2004 (edited) Okay...let me rephrase that.... lol... I know which sockets are being used because my Firewall program let's me know... and C source code is something I don't really want to touch - I'm 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 I'm 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 I'll 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 shouldn't act like this but they are and it's frustrating me as to why?! Dispose should shut down the ports being used by that class... I shouldn't 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... it's ugly... but it works. I'll 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, I'll finese it later. Thanks! Edited January 29, 2004 by bri189a Quote
Recommended Posts