[leecher]

Hi,

Great to hear that it works now!
I'd still be interested in the reason why the registry scan doesn't work on your machine.
I added some debug-output to the driver attached below. To check it, please

1) replace your vidoprt.sys with attached driver
2) Enable kernel debug output by importing enable_dbgflt.reg (you can later remove the key again)
3) reboot
4) Fire up DebugView as administrator. Capture / [x] Capture Kernel, Capture / [x] Enable Verbose Kernel Output
5) Run TESTVGA.COM

Check for output with prefix "videoprt". Should be something like "videoprt found display class key" etc.

Maybe it's some regkey permission issue or something like that...?

[thezedman]

Attached is a copy of the full DebugView outpput log, with the videoport line being:

videoprt found display class key (9/0) videoprt NO AllocConfig (C0000034)KTM: TmRollbackTransaction for tx

This seems surprising, since my Registry does contain a subkey "AllocConfig" at the level it is trying to query.

And oddly, the KEY_GET_VALUE(hkRev, usCls) macro / ZwQueryKeyValue function above that seems to work just fine. Could it be a difference in how Windows 7 handles REG_RESOURCE_LIST entries and/or ZwOpenKey registry access permissions (KEY_ENUMERATE_SUB_KEYS|KEY_QUERY_VALUE)?

As I understand, the code as a whole works properly in Windows XP, but that might be something to double check since it may be possible the code may fix the situation on XP through other unexpected means.

[leecher]

Hi,

This is indeed very suprising. No idea why it doesn't find the key. It is in a volatile registry path, but still, it should be found. The error code clearly indicates that it is unable to find the entry.

So I decided to rework the driver to implement the "official" way to get the resource list via IoGetDeviceProperty API, can you check if this works for you?

However, this method just gets the BootConfig which i.e. is lackign the "normal" VGA-Ports and seems to just contain the special extra ports, so I'm unsure if this works.

[leecher]

Another thing that would be interesting is if you try the following adjustments:

NTSTATUS OpenKey(HANDLE* pkey, HANDLE root, PWSTR name)
{
	UNICODE_STRING usKey;
	RtlInitUnicodeString(&usKey, name);
	attr.RootDirectory = root;
	attr.ObjectName = &usKey;
	return ZwOpenKey(pkey, KEY_READ, &attr);
}

So, using KEY_READ instead of KEY_ENUMERATE_SUB_KEYS|KEY_QUERY_VALUE, because that also includes STANDARD_RIGHTS_READ.
If it doesn't work, this can also be tried:

NTSTATUS OpenKey(HANDLE* pkey, HANDLE root, PWSTR name)
{
	OBJECT_ATTRIBUTES objectAttributes;
	UNICODE_STRING usKey;
	RtlInitUnicodeString(&usKey, name);
	InitializeObjectAttributes( &objectAttributes,
                                &usKey,
                                OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,
                                root,
                                (PSECURITY_DESCRIPTOR) NULL
                                );
	return ZwOpenKey(pkey, KEY_READ, &objectAttributes);
}

Maybe this helps when reading the key? Just guessing.

[thezedman]

I added a couple of extra debug print statements and from what I can tell VideoprtW7_v2 seems to fail at the first for loop, with pszszDeviceList being set to an initial value (In my most recent run, BF130D00).

The other changes did not seem to affect the older algorithm when trying to read AllocConfig. Perhaps, there may be an issue with the way it switches from reading the Class key to the Control key under the same parent key?

[leecher]

Hm, very interesting, both variants work on my physical test machine.
By failing at the loop, do you mean that the break condition (p points to an empty string) is satified on first iteration und therefore the loop isn't entered because returned pszszDeviceList is simply an empty list)?

There is another possibility that comes to my mind:
I tested the code with having the video driver disabled (so that the standard VGA driver gets used, that's the same thing that conhostf does when switching to fullscreen).
Maybe the device path is considered to be inactive when VGA mod is not (yet) turned on and therefore there also is no AllocConfig key (still doesn't explain why you can see it perfectly well in registry)?

One test would be to do IoGetDeviceInterfaces(&Interface, NULL, DEVICE_INTERFACE_INCLUDE_NONACTIVE, &pszszDeviceList) and check if you get back a valid devicec link entry there.
Just guessing.

My next step would probably be to hook up WinDbg to the machine and step into Windows' code in order to find out where this fails. MAybe it is some problem with the registry, as IoGetDeviceInterfaces also searches the registry.