Need some people who liked to test ...

Machiavelli said:
Now I had the time to read your tutorial , Niemiro, and it's great! You really helped me a lot.
Click to expand...

No problem :)

I am very glad that it helped. One feature I would like to see though is automatic opening of the logfile at the end. If you wanted, simply call %SystemRoot%\System32\notepad.exe "full_path_to_logfile"

It is not overly important to get any particular architecture of notepad.exe, so calling System32 copy will make it always work no matter what platform you are on.

Richard
 
Hello all,

I searched now for listing drivers. I don't find much stuff, so I will ask you! Is there any chance to generate a list which drivers are on the system?

I could it's really complicate I think, especially because they are under the same Registry Key. I could formate the ImagePath of all Keys to a normale filepath, ask if it ends with .sys. Is this a good idea? Could I manage this with WMI?
 
Machiavelli said:
Hello all,

I searched now for listing drivers. I don't find much stuff, so I will ask you! Is there any chance to generate a list which drivers are on the system?

I could it's really complicate I think, especially because they are under the same Registry Key. I could formate the ImagePath of all Keys to a normale filepath, ask if it ends with .sys. Is this a good idea? Could I manage this with WMI?
Click to expand...

Hello!

There are a couple of ways. You *could* just use driverquery.exe (System32), perhaps with some arguements.

Or probably better/more powerful/more flexible for further additions, you could just pass HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services. But don't rely on file extension .sys. It is conventional, but not a requirement. Instead use value "Type", and check for data 0x1 or 0x2. Also check value "Start", and check if not at 0x4 (disabled), etc. Log exactly what you find.

And read entirety of this page: CurrentControlSet\Services Subkey Entries

It's old but still accurate, except that I think we now have a "WOW64 = 0x1" value where appropriate.

Also watch out for service keys which don't have all of these values due to both design or corruption. Not all do, don't allow program to crash because of it :)

Richard
 
Last edited:
Thanks, Richard, you helped me a lot. I'll take a closer look at this tomorrow and report back if there are still any problems.
 
Changelog:

Version 1.0.0.
- Tool lists Processes and Services

Version 1.0.0.1
- Tool lists Drivers
- Fixed a bug (When the file doesn't exist then there is a error message)

EDIT:
There's still a bug. I'll come with a new version later.
 
Download:

View attachment MVS.zip

Changelog:

Version 1.0.0.
- Tool lists Processes and Services

Version 1.0.0.1
- Tool lists Drivers
- Fixed a bug (When the file doesn't exist then there is a error message)
- Fixed another bug (Didn't list all drivers)
 
Machiavelli said:
Download:

View attachment 5813

Changelog:

Version 1.0.0.
- Tool lists Processes and Services

Version 1.0.0.1
- Tool lists Drivers
- Fixed a bug (When the file doesn't exist then there is a error message)
- Fixed another bug (Didn't list all drivers)
Click to expand...

Nice! I was actually going to say that the previous version didn't seem to list enough many drivers, I think it listed only WOW64 drivers or something.
 
Dorry, hadn't became the notification that you answered. For now you needn't test it - I'll inform you when you should test.

But a question:

I have began to work on this tool again and I must have realised that there is now an error for the same code.

With this code:

Code: 
 For Each oProcess As Process In Process.GetProcesses
            Try
                sw.Write(oProcess.MainModule.FileName & vbCrLf)
            Catch ex As Exception
                Continue For
            End Try
        Next
It doesn't work - without yes. When I try this Code on another project it works! ?!

Error Message:

A Exception of the type System.ComponentModel.Win32Exception occured in System.dll.

Reason: Access denied?

I'm now really confused because when I use the same code on a new project it works.
 
I know that you're most likely compiling as an x86 executable because that is the default and you probably haven't changed it as you're still learning. If you have a 64 bit machine then I would assume this is because you are enumerating 64 bit processes at the time of the exception. You can't access a 64 bit module from a 32 bit executable. That Try Catch is a bit bulky though. You don't need the defined exception if you don't use it, and you shouldn't need to continue the loop in the Catch block.

I assume 'sw' is an identifier for a StreamWriter though, and I can hopefully assume that you are Dispose()'int of that instance correctly right? :grin1:
 
I know that I can compile it to 64bit and to 32 bit - both version doesn't work.

With Dispose() you mean sw.Close() ?
 
Machiavelli said:
I know that I can compile it to 64bit and to 32 bit - both version doesn't work.

With Dispose() you mean sw.Close() ?
Click to expand...

Define "doesn't work" with exactly what is happening.

Also, no, I mean Dispose(). Close() explicitly acts as a wrapper method for calling Dispose() anyways, so the comparison is almost no different in most cases. I know that Close() for a StreamReader/StreamWriter just calls to dispose directly.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top