WMI Question: How to get display information from multiple monitors attached to PC

Hello everyone,

I have a project that requires me to gather inventory data for my computer. I am having problems trying to get the properties of the monitors attached to my computer.

I have one computer that can potentially use a max of 4 monitors, wherein I have a primary monitor and 3 other potential monitors which act as extension screens when I move my mouse to them ( depending on whether they are connected or not ).

I need to grab the following information from each monitor :

* DeviceId,
* Name,
* Horizontal and Vertical resolution,
* Whether or not the monitor is the primary one ( a true or false value will suffice ).

I tried using the WMI, Win32_DesktopMonitor class but it is only giving me ONE monitor's results ( the primary monitor ).

I then tried using the Win32_PnPEntity class.

This works, and gives me the number of monitors attached to my computer, but it only gives me Name and DeviceId ( no horizontal and vertical resolution information in this class ).

I then tried the Screen class (using the System.Windows.Forms.Screen), however the result is erratic. In one environment, it gives me the right number of monitors attached to my computer, in others, it does not.

Does anyone know of a Class provided by .NET 4 that will help me gather the information I need?

I am using .NET Framework 4 and building my application as a Console Application.

Any suggestions and advise will be highly appreciated.

As a follow up to my post, and for everyone's information, I am using the following environment:

1) .NET 4
2) Visual Studio 2010
3) C# programming language
4) Console Application

That information is in the registry, HKLM-->System-->CurrentControlSet-->Enum-->Display

Check out Microsoft.Win32.Registry.GetValue() for more information. Good luck!

Thanks for your help. I'll try it.

I forgot to add and I apologize for this... this application I am building will eventually be ran as a Windows Service application.

I discovered this during my development ---- when I tried the Screen class (using the System.Windows.Forms.Screen), the result is erratic.

If I ran the program as a pure console application, it works and gives me the right number of monitors attached to my computer, when I ran the same program as a windows service, it does not. It only gives me ONE ( the primary monitor ).

Any suggestions, guidance from anyone with experience on this issue will be highly appreciated. Thank you.

Quote:

---

Originally Posted by mrgr8avill

That information is in the registry, HKLM-->System-->CurrentControlSet-->Enum-->Display

Check out Microsoft.Win32.Registry.GetValue() for more information. Good luck!

---

I tried looking at that section of the registry. It does give me the HardwareID, which identifies the monitor itself. However, I do not have the display horizontal and vertical resolutions from this registry entry.

That is my problem really, some Win32 classes give me one or the other but not both.

Uggh. It may come down to using two different classes to get what you need, or maybe adding a forms app to your project just to be able to use Windows.Forms.Screen class accurately & return the propoer information to your console app. I'm thinking it's workaround time. Sorry I couldn't be of more help, and good luck!

Quote:

---

Originally Posted by JoeJitsu

Thanks for your help. I'll try it.

I forgot to add and I apologize for this... this application I am building will eventually be ran as a Windows Service application.

I discovered this during my development ---- when I tried the Screen class (using the System.Windows.Forms.Screen), the result is erratic.

If I ran the program as a pure console application, it works and gives me the right number of monitors attached to my computer, when I ran the same program as a windows service, it does not. It only gives me ONE ( the primary monitor ).

Any suggestions, guidance from anyone with experience on this issue will be highly appreciated. Thank you.

---

You are going to have a tough time running this as a service, unless you take the settings from the logged on user and send it to your service.

The reason being is that each user on the system could have several different monitor settings. One could have 4 monitors set up, another can have only one, and so on. Code at the service level can't distinguish the settings for each user.

One way around this problem is to run an 'agent' when the user logs on. This agent would detect the monitor settings for that user and update the service (for that user). The agent could also detect display changes and send updates back to the service.

Oh yeah - sorry I missed the update about running as a service. It's not pretty, but you could go the old-fashioned way and run as a forms app launched by the Task Scheduler. I know that's really bad (mmkay) but it could be a viable but ugly workaround in this scenario.

I would approach it as a tray icon app that gets launched with the run registry entry. You can register the run key under the all users key (i.e. HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Run) so the tray icon app would autoload for each user.

Communication between the tray icon app(s) and the service could be done by having the service app host a WCF service. The tray icon app operates a WCF service client for the communication and calls an UpdateDisplay method on the service. Using a WCF service for this communication might seem a bit complicated, but it's actually quite easy.

Hello Arjay,

Thanks for your input.

This project I am writing eventually will have to be run as an AGENT that collects Monitor/Display information and writes the data collected to an XML File. Which means it will eventually be made into a Windows Service Application.

Hence, talking about the SCREEN class I am using, If I ran the program as a pure console application, it works and gives me the right number of monitors attached to my computer. However, when I ran the same program as a windows service, it does not. It only gives me ONE ( the primary monitor ).

I am currently inclined to call the console application that works from my windows service via this line System.Diagnostics.Process("C:\\MyApp\\DisplayMonitorConsoleAppInventoryGrabber.exe"); Where DisplayMonitorConsoleAppInventoryGrabber.exe is my console application that uses the Screen class and collects Monitor data correctly.

I will then tell the DisplayMonitorConsoleAppInventoryGrabber.exe to write the information that it collects into a text file where my windows service can read the data it collects.

Do you think this is a viable solution?

Thanks for your input.

This project I am writing eventually will have to be run as an AGENT that collects Monitor/Display information and writes the data collected to an XML File. Which means it will eventually be made into a Windows Service Application.

Hence, talking about the SCREEN class I am using, If I ran the program as a pure console application, it works and gives me the right number of monitors attached to my computer. However, when I ran the same program as a windows service, it does not. It only gives me ONE ( the primary monitor ).

I am currently inclined to call the console application that works from my windows service via this line System.Diagnostics.Process("C:\\MyApp\\DisplayMonitorConsoleAppInventoryGrabber.exe"); Where DisplayMonitorConsoleAppInventoryGrabber.exe is my console application that uses the Screen class and collects Monitor data correctly.

I will then tell the DisplayMonitorConsoleAppInventoryGrabber.exe to write the information that it collects into a text file where my windows service can read the data it collects.

Do you think this is a viable solution?

It's important to understand the Desktop differences between a logged on user and a Windows service. When you run a Windows service, it runs in a different desktop than a logged in User. In fact, each logged in user runs in its own desktop.

As such, the reason that you only get one monitor returned when running as a service is because that desktop (i.e. the windows service desktop(0) ) has a default non-visible monitor assigned to it. The first logged on user gets a different desktop(1) and might have two monitors configured and the next user (running in desktop(2)) might not have the "extend desktop to other monitors" setting checked so it only sees one monitor.

So monitor count would be something like:
Service 1
User1 2
User2 1

If you run your monitor tool under the service, it will run under the context of the service account and therefore it returns 1 monitor. Your service code could run the tool (Process.Start or runas) under a different user account, but then the service would need the login account credentials of the user you wish to run under.

Given these complications, this is why I suggested the agent approach. If the purpose of the windows service is to do some processing on the monitor settings (like send these settings to some other external service), then the job of the service is to simply receive the settings from each agent and then forward the settings on.

As far as getting the settings from each agent to the windows service, you could use an xml file, but I wouldn't recommend it. The reason being is the reading/writing of that file must be synchronized between the windows service process and the agent process(es); otherwise you have a risk of a race condition (and a corrupted file).