How many Easter eggs have you found in WinXP?

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

VirtualLarry

No Lifer
Aug 25, 2001
56,578
10,215
126
Originally posted by: bsobel
No disagreement. I was just disgreeing that the shell, by default, is running at anything other than 'normal' priority and that everything it launches (by default) is also running at anything other than 'normal' priority.
I guess I would naively assume that any child processes would briefly inherit the parent processes' base prio level, before being set. I haven't really investigated that, I guess I should.
Originally posted by: bsobel
Ok, before I make any assumptions on your config here. Why is it you have multiple explorer.exe processes running in the same workstation? I can think of two common reasons. One is that you've tweaked the registry and told explorer to launch new windows as a seperate process (IE supports doing this also).
Well, when I log in to Windows', the primary (outermost, user-shell) instance of Explorer.exe is launched, and then I generally have another one open as an app most of the time, for file-management operations. Yes, I set the option to "Open new windows in another process" - I absolutely cant stand it when one Explorer/IE windows would crash, and bring down every other window with them. :(

No fake explorer.exe malware, that I can see. Btw, I'm not "arguing" about any of this, I find it more of an intellectual curiosity at this point. I don't have TweakUI installed on this machine, but perhaps some other app has fiddled with it. I also notice that my LinkSys WUSB54Gv1 USB2.0 802.11g card's drivers, which appear to involve both some sort of launcher .exe, as well as a custom-written system-service (running inside that launcher .exe, not inside one of the "well known" service-host executables), is also running at "high" priority. Have no idea if that's related in any way to the Explorer.exe issue. Also, CSRSS.EXE, is likewise "high".

Ok, adding the "Base Pri" column in Task Manager, gives me these set to "high":
taskmgr.exe, WUSB54Gv4.exe, WINLOGON.EXE, CSRSS.EXE. The user-shell Explorer.exe is in fact "normal", again, my apologies for the mistaken observation. But when I click on my Explorer.exe shortcut, on my taskbar's default quicklaunch toolbar, that instance does indeed get set to "high". How strange. Double-clicking the desktop icon for IE - "normal". Double-clicking Explorer - "high. The shortcut only contains this: "%SystemRoot%\explorer.exe" Ok, I tried double-clicking, and also right-clicking and selecting "Explorer", on the "My Network Neighborhood" desktop shortcut, and I was wrong before, those actually only open additional windows, of the same parent Explorer.exe instance, they don't open another one.

Hmm. Could any of this have to do with user login credentials, is there some "phantom" on my box intercepting my CreateProcess calls, or what? I have two accounts on this box, mine, which is part of Administrators, as well as the actual Administrator account, which I don't use. Oh well, I have no clue at this point, and need to get some sleep, goodnight all.
 

bsobel

Moderator Emeritus<br>Elite Member
Dec 9, 2001
13,346
0
0
I guess I would naively assume that any child processes would briefly inherit the parent processes' base prio level, before being set. I haven't really investigated that, I guess I should.

The caller specifies the new process priority when calling createprocess. By default, if a priority is not defined the process defaults to normal The exception is if the caller is running at idle or below_normal, then the default is the default priority of the caller. This is the reason the original suggestion by My Von Dyk works. If explorer is below normal, things launched from it retain that. However, it shouldn't be holding true if explorer is high priority (unless explorer was specifically coded to launch children based on its current priority level). Now I'm basing this on my recolection the explorer code admittidly from awhile ago, but I don't recall any place where they specifically set the priority of launched apps based on explorer itself.

Well, when I log in to Windows', the primary (outermost, user-shell) instance of Explorer.exe is launched, and then I generally have another one open as an app most of the time, for file-management operations. Yes, I set the option to "Open new windows in another process" - I absolutely cant stand it when one Explorer/IE windows would crash, and bring down every other window with them. :(

Ok, that makes sense, and would explain why I may be seeing something different. I only have the one copy of explorer running. It wouldn't seem unreasonable (as you already mentioned) for them to specifically launch this second process with a higher priority). Apps launched from it would still be normal (so the universe as we know it remains in balance ;))

Btw, I'm not "arguing" about any of this, I find it more of an intellectual curiosity at this point.

Didn't think you were, got me curious too.

Bill
 

MyK Von DyK

Member
Nov 24, 2004
63
0
0
Taken from WinAPI guide:

-----------------
Priority Boosts
-----------------

Each thread has a dynamic priority. This is the priority the scheduler uses to determine which thread to execute. Initially, a thread's dynamic priority is the same as its base priority. The system can boost and lower the dynamic priority, to ensure that it is responsive and that no threads are starved for processor time. The system does not boost the priority of threads with a base priority level between 16 and 31. Only threads with a base priority between 0 and 15 receive dynamic priority boosts.

The system boosts the dynamic priority of a thread to enhance its responsiveness as follows.

· When a process that uses NORMAL_PRIORITY_CLASS is brought to the foreground, the scheduler boosts the priority class of the process associated with the foreground window, so that it is greater than or equal to the priority class of any background processes. The priority class returns to its original setting when the process is no longer in the foreground.

· When a window receives input, such as timer messages, mouse messages, or keyboard input, the scheduler boosts the priority of the thread that owns the window.
· When the wait conditions for a blocked thread are satisfied, the scheduler boosts the priority of the thread. For example, when a wait operation associated with disk or keyboard I/O finishes, the thread receives a priority boost.

After raising a thread's dynamic priority, the scheduler reduces that priority by one level each time the thread completes a time slice, until the thread drops back to its base priority. A thread's dynamic priority is never less than its base priority.



------------------------------
ShellExecute Function Call
------------------------------

The ShellExecute function opens or prints a specified file. The file can be an executable file or a document file.

HINSTANCE ShellExecute(

HWND hwnd, // handle to parent window
LPCTSTR lpOperation, // pointer to string that specifies operation to perform
LPCTSTR lpFile, // pointer to filename or folder name string
LPCTSTR lpParameters, // pointer to string that specifies executable-file parameters
LPCTSTR lpDirectory, // pointer to string that specifies default directory
INT nShowCmd // whether file is shown when opened
);


Parameters

hwnd

Specifies a parent window. This window receives any message boxes that an application produces. For example, an application may report an error by producing a message box.

lpOperation

Pointer to a null-terminated string that specifies the operation to perform. The following operation strings are valid:

String Meaning
"open" The function opens the file specified by lpFile. The file can be an executable file or a document file. The file can be a folder to open.
"print" The function prints the file specified by lpFile. The file should be a document file. If the file is an executable file, the function opens the file, as if "open" had been specified.
"explore" The function explores the folder specified by lpFile.


The lpOperation parameter can be NULL. In that case, the function opens the file specified by lpFile.

lpFile

Pointer to a null-terminated string that specifies the file to open or print or the folder to open or explore. The function can open an executable file or a document file. The function can print a document file.

lpParameters

If lpFile specifies an executable file, lpParameters is a pointer to a null-terminated string that specifies parameters to be passed to the application.
If lpFile specifies a document file, lpParameters should be NULL.

lpDirectory

Pointer to a null-terminated string that specifies the default directory.

nShowCmd

If lpFile specifies an executable file, nShowCmd specifies how the application is to be shown when it is opened. This parameter can be one of the following values:

Value Meaning
SW_HIDE Hides the window and activates another window.
SW_MAXIMIZE Maximizes the specified window.
SW_MINIMIZE Minimizes the specified window and activates the next top-level window in the Z order.
SW_RESTORE Activates and displays the window. If the window is minimized or maximized, Windows restores it to its original size and position. An application should specify this flag when restoring a minimized window.
SW_SHOW Activates the window and displays it in its current size and position.
SW_SHOWDEFAULT Sets the show state based on the SW_ flag specified in the STARTUPINFO structure passed to the CreateProcess function by the program that started the application. An application should call ShowWindow with this flag to set the initial show state of its main window.
SW_SHOWMAXIMIZED Activates the window and displays it as a maximized window.
SW_SHOWMINIMIZED Activates the window and displays it as a minimized window.
SW_SHOWMINNOACTIVE Displays the window as a minimized window. The active window remains active.
SW_SHOWNA Displays the window in its current state. The active window remains active.
SW_SHOWNOACTIVATE Displays a window in its most recent size and position. The active window remains active.
SW_SHOWNORMAL Activates and displays a window. If the window is minimized or maximized, Windows restores it to its original size and position. An application should specify this flag when displaying the window for the first time.


If lpFile specifies a document file, nShowCmd should be zero.



Return Values

If the function succeeds, the return value is the instance handle of the application that was run, or the handle of a dynamic data exchange (DDE) server application.
If the function fails, the return value is an error value that is less than or equal to 32. The following table lists these error values:

Value Meaning
0 The operating system is out of memory or resources.
ERROR_FILE_NOT_FOUND The specified file was not found.
ERROR_PATH_NOT_FOUND The specified path was not found.
ERROR_BAD_FORMAT The .EXE file is invalid (non-Win32 .EXE or error in .EXE image).
SE_ERR_ACCESSDENIED The operating system denied access to the specified file.
SE_ERR_ASSOCINCOMPLETE The filename association is incomplete or invalid.
SE_ERR_DDEBUSY The DDE transaction could not be completed because other DDE transactions were being processed.
SE_ERR_DDEFAIL The DDE transaction failed.
SE_ERR_DDETIMEOUT The DDE transaction could not be completed because the request timed out.
SE_ERR_DLLNOTFOUND The specified dynamic-link library was not found.
SE_ERR_FNF The specified file was not found.
SE_ERR_NOASSOC There is no application associated with the given filename extension.
SE_ERR_OOM There was not enough memory to complete the operation.
SE_ERR_PNF The specified path was not found.
SE_ERR_SHARE A sharing violation occurred.


Remarks

The file specified by the lpFile parameter can be a document file or an executable file. If the file is a document file, the ShellExecute function opens or prints it, depending on the value of the lpOperation parameter. If the file is an executable file, the ShellExecute function opens it, even if lpOperation specifies printing.
You can use ShellExecute to open or explore a shell folder. To open a folder, use either of the following calls:

ShellExecute(handle, NULL, path_to_folder, NULL, NULL, SW_SHOWNORMAL);

or


ShellExecute(handle, "open", path_to_folder, NULL, NULL, SW_SHOWNORMAL);


To explore a folder, use the following call:

ShellExecute(handle, "explore", path_to_folder, NULL, NULL, SW_SHOWNORMAL);


If lpOperation is NULL, the function opens the file specified by lpFile. If lpOperation is "open" or "explore", the function will force an open window or explorer.

---------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------
 

bsobel

Moderator Emeritus<br>Elite Member
Dec 9, 2001
13,346
0
0
And ShellExecute calls down to CreateProcess, where the launched apps new priority can be provided (or it will default based on the rules I previously posted).

Certainly not disagreeing with anything you just posted, but what were you trying to clarify? Not sure there is much less you, I, VL or anyone is really disagreeing on in the thread.

Still curious (you can PM if you want) what your background is. And I reiterate my original apology, but I was disapointed by your prior post were you opted out. I did think I answered your initial response post pretty fairly.

Bill
 

VirtualLarry

No Lifer
Aug 25, 2001
56,578
10,215
126
Really, just a real simple question. On XP SP1, why does starting a child process (an instance of Explorer.exe), default to "high" priority, rather than "normal", like the parent? Where in the world does it pick up that value from, and why don't other apps launched via Explorer.exe, also start at "high"? I wonder if there is something else going on here, specifically, perhaps an actual bug relating to the implimentation of the "Open new explorer windows in a seperate process" feature, somewhere in some system .DLL. I don't have access to a debug-kernel version of XP right now, otherwise I'd use that to try to see what is happening here.
 

bsobel

Moderator Emeritus<br>Elite Member
Dec 9, 2001
13,346
0
0
Originally posted by: VirtualLarry
Really, just a real simple question. On XP SP1, why does starting a child process (an instance of Explorer.exe), default to "high" priority, rather than "normal", like the parent? Where in the world does it pick up that value from, and why don't other apps launched via Explorer.exe, also start at "high"? I wonder if there is something else going on here, specifically, perhaps an actual bug relating to the implimentation of the "Open new explorer windows in a seperate process" feature, somewhere in some system .DLL. I don't have access to a debug-kernel version of XP right now, otherwise I'd use that to try to see what is happening here.

If it's happening (and I have no reason to think it's not now that we've accounted for how our configs are different) I'm sure it's intentional.
 

VirtualLarry

No Lifer
Aug 25, 2001
56,578
10,215
126
Originally posted by: MyK Von DyK
VirtualLarry, please read my first reply to your "problem", I think it might solve it... Best, MyK
Except that seems to have no direct relevance, since I've not run any sort of "tweaker" program on this OS install, and I'm not stupid enough to think that somehow running all of my apps at "above normal" or "high" process priority will make them run any faster. Heck, I could run them all at "below normal", and as long as they are all at the same prio level, the OS scheduler should divide up CPU time the same way as at "normal" priority.

Also, the only user-launched process that seems to default to "high" priority, is the child instance of Explorer.exe, all of my other apps launch at "normal". Very wierd.... unless - is there a way to mark a PE executable to indicate the base process priority level, like you can for "sticky" CPU affinity settings? If that's possible, then perhaps the first instance is being launched at "normal" priority, by WinLogon or CSRSS or whatever system process launches the initial user shell, ignoring any "sticky priority" settings, whereas, launching the .exe directly, doesn't ignore them. I'll scrounge though my registry and see if anything sticks out there as well, as far as sticky priority settings. There's got to be an answer to this issue, somewhere.

Edit: It's not really a "problem", I just have a bizarre desire to learn about all trivial technical minuatae of this sort. And my original hypothesis about the user-shell being set to "high" was apparently wrong, it's the second, child app instance of Explorer that is "high", the user-shell is "normal".

Maybe MS actually intended for the user-shell to be "high" as well, but somehow, screwed up, and the implimentation ended up backwards? It wouldn't entirely surprise me.
 

bsobel

Moderator Emeritus<br>Elite Member
Dec 9, 2001
13,346
0
0
Also, the only user-launched process that seems to default to "high" priority, is the child instance of Explorer.exe, all of my other apps launch at "normal". Very wierd.... unless - is there a way to mark a PE executable to indicate the base process priority level, like you can for "sticky" CPU affinity settings? If that's possible, then perhaps the first instance is being launched at "normal" priority, by WinLogon or CSRSS or whatever system process launches the initial user shell, ignoring any "sticky priority" settings, whereas, launching the .exe directly, doesn't ignore them. I'll scrounge though my registry and see if anything sticks out there as well, as far as sticky priority settings. There's got to be an answer to this issue, somewhere.

What is the issue we are trying to solve? It appears to be deliberate, much like taskman being launched as high. Only shows up if you enable multiple windows as sepeare processes, so we haven't noticed until now.

Bill