How to force Windows Device Manager refresh device name display after I change FriendlyName registry value - windows

Microsoft WDK's Toaster sample code contains a ClassInstaller example(tostrcls.dll). It shows the ability to customize "device friendly name" displayed by Device Manager. The ability is achieved by modifying FriendlyName's value for the device's hardware key . After modifying FriendlyName, a close and reopen of the Device Manager window(devmgmt.msc) will reflect such changes. So far, so good.
However, in order to tell Device Manager window to reflect the change immediately(without close and reopen its window), some extra code has to be run. classInst.c takes the following way:
spDevInstall.FlagsEx |= DI_FLAGSEX_PROPCHANGE_PENDING;
SetupDiSetDeviceInstallParams(Params->DeviceInfoSet,
Params->DeviceInfoData,
&spDevInstall);
That works, but NOT optimal. DI_FLAGSEX_PROPCHANGE_PENDING causes the device to go through a STOP/START cycle. I mean, the driver's ToasterEvtDeviceReleaseHardware and ToasterEvtDevicePrepareHardware get executed. I think this is an undesired side-effect.
So my question is clear. Is there a way to refresh Device Manager's display without bothering with the driver code?

I got the answer from WDK7 PnpPorts project(which is the ClassInstaller that implement the Windows COM Port "Port Setting" tab).
Just change
spDevInstall.FlagsEx |= DI_FLAGSEX_PROPCHANGE_PENDING;
to
spDevInstall.Flags |= DI_PROPERTIES_CHANGE;
all done.
Note: The device-restarting behavior of DI_FLAGSEX_PROPCHANGE_PENDING is documented in WDK7 chm page "DIF_ADDPROPERTYPAGE_ADVANCED" but not in "SP_DEVINSTALL_PARAMS". I only check the latter, so missed it.

Related

Firefox extension - Share common state between two or more windows

I am developing firefox extension.
Problem is that when i open second window (Ctrl + N) my extension has new state for new opened window.
If I reacts or changes on second window it never affect on first window or vice versa.
Ex
Installed extension on Firefox
first window opened. My extension proper functioning, change state, login, view data etc
then opened second. My extension goes new state I cant get previous states (first window states).
How can maintain same state between first and second or other firefox opened windows.?
Am I correct to assume you're developing a XUL overlay add-on, and not an SDK add-on?
One way to share state between windows is to use Javascript code modules. A code module will only be loaded once (unless explicitly unloaded) and therefore will expose the same data to multiple windows. Be sure to read the "Sharing objects using code modules"., However, please note that therefore when closing a window, any state associated with it and stored within the code module must be cleaned up, or would leak otherwise.
If you're using the SDK instead, your main.js module is already the equivalent of a code module. Content scripts may use message passing to store and retrieve state from your module.

Understanding SystemParametersInfo SPI_SETFOREGROUNDLOCKTIMEOUT

My App needs to get the focus when it get's called by an external tool (via an API), i know that the default is, that it should just flash in the Taskbar, but in this case this is absolutely not the behaviour that i want. In this case i try to get the focus by "this.Activate()" (C#).
This is where the ForeGroundLockTimeOut comes into play.
However, I got a little problem understanding the SystemParameterInfo SPI_SETFOREGROUNDLOCKTIMEOUT.
I know that it's used to set the ForeGroundLockTimeOut which defines how long your app has to wait until it gets the focus it requested.
(for further information the variable "val" is an IntPtr that is set to 0)
SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT,0,val,SPIF_SENDWININICHANGE + SPIF_UPDATEINIFILE);
this one will change the Registry key that that handles the timeout (HKEY_CURRENT_USER\Control Panel\Desktop\ForeGroundLockTimout)
Since this will change the behaviour of all apps, it's really the last resort to use.
Now i thought what if i don't update the registry key. So i tried this:
SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, val, 0);
However it doesn't change the behavior of my app in any way, but
SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT,0,val,SPIF_SENDWININICHANGE);
does.
What i do not understand is why this only works for my app, which is absolutely what i want, but i do not understandit .Why do i have to broadcast a change, that only works for my app, when there has been no change made to any registry key or whatsoever, and why does this work only for my app.
Note: If you want to test this behavior, test it when Visual Studio is not running, while it's running (even if this Solution is not loaded) it changes the behavior of the App into getting focus in any case.
This is not a per-app setting, it is a global system setting. There's no way to set it for just your application, so when you call SystemParametersInfo with 0 for the last parameter, nothing happens.
On the other hand, when you use SPIF_SENDWININICHANGE, the new setting gets broadcast in the form of a WM_SETTINGCHANGE message. (Which is why manually editing the registry is the wrong thing to do; always call the documented API.)
Aside from that, this code is wrong:
SPIF_SENDWININICHANGE + SPIF_UPDATEINIFILE
To concatenate two flags, you must use the boolean OR operator (|), not the addition operator (+). In this particular case, because 0x1 + 0x2 and 0x1 | 0x2 are both equal to 3, it seems to work, but that's just an accident.
The real solution to this problem needs not involve manipulating global settings (because you surely don't want to do that on client machines, even if you're OK with it on your own). You need to work with the system, rather than trying to work against it. In the system's model, the process that currently has the focus is the one with the privilege of setting/changing the focus. So there are basically three options:
Just have the external tool call SetForegroundWindow itself and pass your application's window as the parameter. This altogether avoids your app having to activate itself.
Use the AllowSetForegroundWindow function to delegate the external tool's foreground-window-setting privileges to your application. It should call this function, passing the ID of your app's process as the parameter. That way, when your app calls SetForegroundWindow, it will work as expected.
Depending on how your tool and application are designed, you could just have the external tool launch the application. Like the documentation says, if a process is launched by the foreground process, it is allowed to set the foreground window.
SPIF_UPDATEINIFILE--Writes the new system-wide parameter setting to the user profile.
SPIF_SENDCHANGE--Broadcasts the WM_SETTINGCHANGE message after updating the user profile.

Setting the Debug version of the Direct3D runtime won't stick

When I open the DirectX control panel and open the Direct3D 9 tab and set "Use Debug Version of Direct3D 9" and hit "OK" or "Apply," there are no errors. If I open the control panel again, it is back to "Use Retail Version of Direct3D 9." When I try to debug my application, I don't get any output from Direct3D.
When I last did this a few months ago, everything worked correctly and I got debug output.
Running the control panel as Administrator doesn't seem to make a difference and the registry key mentioned here http://www.gamedev.net/topic/514529-cant-use-debug-version-of-direct3d/ is set to one.
What else can I try?
Same thing happened to me. It looks like that TrustedInstaller took ownership of some registry keys (including HKLM/SOFTWARE/Microsoft/Direct3D which dxcpl modifies).
Found a solution here. You just have to change ownership of that regkey.
I've seen this happen and sort of collected best practices to try and get this thing working online - you can try it
1.) There's a separate control panel for x86 and x64 applications in DirectX, There is the DirectX Control Panel which comes with the sdk and there you can set to use the d3d debug runtime and the verbosity level. There is also an option for shader debugging and memory check.
2.) Link against d3dx9d.lib instead of d3dx9.lib
3.) Try adding #pragma comment(lib, "d3dx9d")
4.) Use #define D3D_DEBUG_INFO, but use that before including the d3d9 headers.
5.) Check the Use Debug Version of Direct3D 9 in the properties window like so
http://i.stack.imgur.com/WoZAH.png
6.) Use a tool like DebugView
Sources:
http://www.gamedev.net/topic/514529-cant-use-debug-version-of-direct3d/
https://gamedev.stackexchange.com/questions/24541/cant-get-debug-spew-for-direct3d9
for me the solution was this:
"Looking at the permissions on the key can you not hit the "advanced" button? then click the "owner" tab put a check in the bottom box, then highlight the administrators group, then check "take ownership"."
via: http://www.tomshardware.co.uk/forum/238556-45-cannot-modify-delete-change-permissions-registry
after doing this i was able to give my user full access to HKLM/SOFTWARE/Microsoft/Direct3D and then the ctrlpanel kept its settings.

Using Google Chrome Frame as a "closed container" with HandleTopLevelRequests

Can anyone explain what using GCF as a "closed container" actually means?
I understand from this link that you enable this mode of operation using the HandleTopLevelRequests registry key.
I actually stumbled onto this setting as a way to prevent the Developer Tools window from automatically closing upon postbacks/redirects. That default behavior really makes the Network tab almost useless. :(
By setting the HandleTopLevelRequests registry key as described in the link above, the Developer Tools window remains open like I want.
I just don't know if this is a setting I should leave in place because I don't really understand what it's doing.
Or I suppose another way to ask it is, why wouldn't you want the HandleTopLevelRequests setting in place?
**Another registry key named UseChromeNetworking seems to often be used in conjunction with HandleTopLevelRequests. Bonus points for any details on it as well. :)
Any info at all would be appreciated-

How to get ONLY w3wp instances when specifying performance counters for Perfmon/LogMan on Windows?

Hopefully this question has a simple answer i'm overlooking! I have an IIS webserver with multiple sites on it. In Perfmon, they show up as w3wp#1, w3wp#2, etc... I'm writing a Logman script that will collect performance counter data using the counters/instances that I specify and I want to ONLY collect any w3wp worker processes.
I've tried a couple ways, but no luck:
\.NET CLR Memory(*w3wp*)\
\.NET CLR Memory(w3wp#*)\
\.NET CLR Memory(w3wp*)\
I've looked at the documentation here, and it seems like it claims to support wildcards, but not partial matches. I'm not sure what to make of that. Is there any way accomplish what I want? Hope I explained this well enough. Let me know if more details are needed.
Thanks!
There is a way to display the instance by appending Process Id to it. Since ProcessId do not change it helps determining the correct instance. This post describes the method - Perfmon: Identifying processes by PID instead of instance.
Relevant part from the link:
Making below registry change will display processes in the format of **ProcessName_PID** instead of **ProcessName#1**.
Click Start, click Run, type regedit, and then click OK.
Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance
On the Edit menu, click New, and then click DWORD Value.
Right-click New Value #1, click Rename, and then type ProcessNameFormat to name the new value.
Right-click ProcessNameFormat, and then click Modify.
In the Data value box, type one of the following values, and then click OK:
1: Disables PID data. This value is the default value.
2: Enables PID data.
Exit Registry Editor.
Warning: Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
Important: If you enable this feature, you may be unable to monitor process-specific information by using third-party utilities or custom-made programs, and this functionality may change at any time in the future without notice.
Hope it helps someone.
I came up with a custom batch script that find the application pool ID, PID, and associates it with the IIS worker process in question. From there, I can manually FIND and REPLACE a generic placeholder in my perfmon configuration file to start collecting for the specific site(s). I can supply some details if there is interest.

Resources