tlist.exe is from reskit. If you don't have it, you can check loaded modules using built in debugger:
c:\>ntsd -pv -pn explorer.exe
then in the ntsd window type
0:000> lmf
0:000> q
By the way, soft pagefaults are not 'worthless'. This is how virtual memory works - basically textbook OS design stuff... Fairly well documented in books such as Inside Windows 2000.
I think what really does it is that I program, and play video games on the box, while running dual view, and I like to alt+tab out of directx applications as well. I usually crash when task switching, especially from or to a game. It's actually rather annoying and kind of defeats the purpose of having a multitaking OS...
OS crashes or application crashes? If you get blue screens switching from a game it's very likely a video driver problem.
Usually, after about 2 weeks, explorer.exe will absorb 90-100MB out of my precious little 768MB.
Do you have any plugins (like shell extensions) installed? If there are any 3rd party dlls loaded into explorer process they can be leaking memory. Run 'tlist explorer' to see what dlls are loaded.
And now that I look at it, I disabled virtual memory...
Don't do this. Most of the time this either has no effect on performance or actually hurts it.
Why am I getting page faults?
If you mean the 'Page Faults' column in task manager, this includes soft faults, like when a page is moved from an in-memory standby list to a process working set. These are relatively cheap.
If you're seeing hard page faults (that is, pages are actually read from disk - you can check perfmon counters like Memory\Pages/sec to see if this is what's happening) then it could be code that was paged out (executables are normally paged to their own file on disk instead of pagefile) or pages from a memory mapped file. The fact that you set pagefile size to 0 doesn't mean there will be no paging.
Explorer is page faulting about every second, it's really kind of disturbing, considering this computer is devoid of swap space.
Are you seeing these in Task Manager? That's a side effect of running task manager - the cpu usage icon in the taskbar is animated, and whenever it changes (1 sec by default) there's a soft pagefault. If you quit task manager, these pagefaults will stop. The perf impact of this is minimal so you can basically ignore it.
The problem lies in the idiotic decision to make the header files modifiable by anyone.
Huh? VC installs headers, libs etc under %programfiles%, which means you have to be an admin to modify them.
Re:Program Not Responding
on
PC Annoyances
·
· Score: 1
Well it does tell you the main window title of the process. What else do you need? Process id might be useful for people who know what that is, but most users would just be confused by it.
Re:Program Not Responding
on
PC Annoyances
·
· Score: 1
Sometimes a GUI process might appear to be hung but would still close if you send WM_CLOSE to its main window. This is better than terminating the process so when you do "End Task" in task manager, it tries this first and if the process doesn't respond it then shows this dialog (btw the timeout is more like 5 seconds).
If you want to kill the process immediately, go to the Processes tab (or right-click the task and say Go to process) the click on End Process.
Re:Program Not Responding
on
PC Annoyances
·
· Score: 1
On XP and win2003 you can use tasklist.exe and taskkill -f. This should be just as effective as pskill.
Taskkill will enable debug privilege (so admins can open processes they don't own) and call TerminateProcess. In rare cases (usually when a process is stuck in some kernel mode driver and the driver can't cancel IO request) it will fail to kill the process, but then pskill would fail also.
By the way, you can get detailed descriptions for almost all possible bugcheck codes if you install NT debugging tools. The docs even have basic debugging/troubleshooting steps for most common problems.
For example, this is the explanation of the 4 bugcheck parameters on the IRQL_NOT_LESS_OR_EQUAL blue screen:
The following parameters are displayed on the blue screen.
1 Memory referenced
2 IRQL at time of reference
3 0: Read 1: Write
4 Address which referenced memory
An obvious example is integrating their Web Browser into their OS to screw Netscape, a political decision taken by his Billship. Bugs in IE lead to the equivalent of root exploits, bugs in Mozilla mean that one user account can be compromised.
That's an interesting claim. Do you have any specific examples of this actually happening?
As far as I know, all IE code runs as the user which means exploits in IE can't automatically elevate to root.
I even went to the security bulletin search, searched for IE6 bugs and clicked on several at random. They all had this text:
If an attacker exploited these vulnerabilities, they would gain only the same privileges as the user.
So, again, where did you get this idea that IE bugs lead to root exploits?
I'm sticking with label of pervasive since the number of applications that *don't* interact are quite rare in windows, as opposed to linux. Services are a fairly small subset and quite tightly controlled in comparison.
Let's clarify the terminology. For the purposes of this discussion, let's say an "application" is a process running as the interactive user. It could be vulnerable to message attacks, but it wouldn't matter because it has the same privileges as the user.
A "service" is a process running as some privileged user. It could be a real service, or a COM+ application, or something like that.
An "interactive service" is a service that has taken the steps necessary to inject its UI into the interactive desktop.
So here's what we have:
Shatter attacks only matter for interactive services.
Most built-in services are not interactive.
Interactive services have been known to be a security risk for a long time.
Instead of using interactive services, developers have been encouraged to use a separate process running as the interactive user and some form of IPC to talk to the service (this is for example how SQL Server draws its icon in the taskbar).
If people ignore the warnings and decide to use interactive services, they can be vulnerable for two reasons: because they don't validate the messages themselves (this would be no different from opening a socket and not validating the data that comes in) or because of the bugs in the OS.
All known vulnerabilities in the OS code that could lead to a compromize of an interactive service have been fixed.
There are in fact problems in Windows that could be called "fundamental" and difficult to fix. But this isn't one of them. It boils down to the fact that if you accept input from untrusted sources, you have to validate it. Validating all possible windows messages is hard, so the best solution is to not accept them in the first place, which means not having any UI in a service unless you know what you're doing.
Windows Messaging was simply designed wrong. It does no verification of which process sent the message.
Except that both processes have to be running on the same windowstation/desktop to be able to exchange messages. Thus the majority of services are not vulnerable to any of this - you have to *explicitly* configure your service to create any UI on the interactive desktop. People who understand how this works knew about the security implications of having interactive services long before the term "shatter attacks" appeared.
Thus, there is a pervasive and *unremovable* hole in Windows design.
It's not "pervasive" because by default services are not vulnerable. It's not "unremovable" because all known places where even interactive services could be exploited are fixed now. If you know otherwise, I'd like to see more details.
How about you do this little experiment: Create a new local user on an XP Pro box (all default settings), and try to delete something from %systemroot% or %programfiles%. Access denied? Good.
Not surprizing, actually, given the default permissions:
Yes, this is the right way to contact the MS Security Response Center. This is what most people who actually find vulnerabilities do. And no, it's not better to email individual employees - they will just forward your email to MSSRC.
What exactly was "egregiously non-compliant"? I might be wrong, but I thought most (if not all) compatibility issues were fixed long before Sun forced MS to stop shipping its JVM.
I think Sun was actually complaining about things like J/Direct which were making it too easy to write Windows programs in Java. Sun's solution (JNI) was purposefully complicated so that interoperability with native code was a pain in the ass.
Click all you want. Its pointless once they got enough crash info.
It's not pointless. They don't store every crash dump, but the total number of crashes is recorded. Higher numbers mean higher chances of a fix. Of course, that's assuming that the app didn't wipe out its stack so the fault goes into some generic "we have no idea what's going on" bucket, and that all crashes are actually identical or similar enough, and that the problem is actually in Windows and not the app etc.
As for making the crash info available to 3rd party vendors - it already is. You can see the crash data for your applications if you participate in the "certified for windows" program or something like that.
And of course there are plenty of people who choose not to send the crash report to MS, or, even more likely, do not (*gasp*) have always-on-connections and cannot send the report to MS
Then you can use queued mode which doesn't require always-on connection. This is from the help for the error reporting settings dialog:
Specifies whether the system reports program errors in queued mode. The queued mode displays the last ten errors the next time the Administrator logs on to the computer. Each error is displayed in its own window so that the Administrator can choose which errors to report to Microsoft over the Internet.
You can already do this with Windows XP and Windows Server 2003. There is a security policy that allows you to prevent the system from running any binaries that you didn't sign.
There is a huge difference between this and what a Palladium based system could potentially do. Software Restriction Policies in XP and Win2003 are not bulletproof. They can protect users from accidentally running a trojan/virus but they cannot guarantee that somebody hasn't modified the OS itself.
This is a fundamental problem with traditional (non-Palladium based) systems. OS can give you some protection but to guarantee the integrity of the OS itself you need some kind of hardware support.
So, I'll ask again - what is taking MS so long? Linux, with full application support, both 64 and 32 bit, will be ready at Opteron release... MS is shooting for a six month later release date, and knowing Microsoft's record on hitting such dates I'm not optimistic.
MS has been working on Win2003 which is a major release supporting two architectures (x86 and IA64). Adding AMD64 support would have delayed it. Looks like they felt it was more important to release Win2003 sooner than to have AMD64 support sooner.
Yep, I knew all that...still why was it so much easier to port Linux?
NT has been running on AMD64 for more than a year now. There's a difference between porting the kernel and releasing a fully tested product with major application support (Exchange, SQL etc).
So your theory is that Microsoft has been sitting on it's hands all these years without porting to any of the readily available 64-bit platforms? Including Itanic, which has been around in beta incarnations for several years?
Of course not. In fact, there are released Itanium versions of XP and Windows 2000. I heard that before that, there was an internal 64-bit Alpha version of Win2K.
Out of this will come lots of students thinking about security the Microsoft way. They'll believe that more security features (ACLs, etc.) in a system make it more secure.
Why do you think so? The following is a quote from a MS Press book ("Writing Secure Code"):
Security principles to live by:
...
Remember that security features != secure features
Power Users have write access to %programfiles%, %systemroot% and HKLM\Software. A power user could modify a CLSID key to point to his own dll and wait for an admin to instantiate this object. Or replace a file that's not protected by Windows - such as a dll/exe from a 3rd party product installed to Program Files.
Like many other features in Windows (such as 'disable command prompt' policy) Power Users exist for ease of administration, not for security. It can prevent users from shooting themselves in the foot but it will not stop a determined hacker.
On the other hand, BUILTIN\Users does represent real security boundary. There is no way a normal user can elevate himself to an admin.
Slashdot Mirror
c:\>ntsd -pv -pn explorer.exe
then in the ntsd window type
0:000> lmf
0:000> q
By the way, soft pagefaults are not 'worthless'. This is how virtual memory works - basically textbook OS design stuff... Fairly well documented in books such as Inside Windows 2000.
OS crashes or application crashes? If you get blue screens switching from a game it's very likely a video driver problem.
Usually, after about 2 weeks, explorer.exe will absorb 90-100MB out of my precious little 768MB.
Do you have any plugins (like shell extensions) installed? If there are any 3rd party dlls loaded into explorer process they can be leaking memory. Run 'tlist explorer' to see what dlls are loaded.
And now that I look at it, I disabled virtual memory...
Don't do this. Most of the time this either has no effect on performance or actually hurts it.
Why am I getting page faults?
If you mean the 'Page Faults' column in task manager, this includes soft faults, like when a page is moved from an in-memory standby list to a process working set. These are relatively cheap.
If you're seeing hard page faults (that is, pages are actually read from disk - you can check perfmon counters like Memory\Pages/sec to see if this is what's happening) then it could be code that was paged out (executables are normally paged to their own file on disk instead of pagefile) or pages from a memory mapped file. The fact that you set pagefile size to 0 doesn't mean there will be no paging.
Explorer is page faulting about every second, it's really kind of disturbing, considering this computer is devoid of swap space.
Are you seeing these in Task Manager? That's a side effect of running task manager - the cpu usage icon in the taskbar is animated, and whenever it changes (1 sec by default) there's a soft pagefault. If you quit task manager, these pagefaults will stop. The perf impact of this is minimal so you can basically ignore it.
Huh? VC installs headers, libs etc under %programfiles%, which means you have to be an admin to modify them.
Well it does tell you the main window title of the process. What else do you need? Process id might be useful for people who know what that is, but most users would just be confused by it.
If you want to kill the process immediately, go to the Processes tab (or right-click the task and say Go to process) the click on End Process.
Taskkill will enable debug privilege (so admins can open processes they don't own) and call TerminateProcess. In rare cases (usually when a process is stuck in some kernel mode driver and the driver can't cancel IO request) it will fail to kill the process, but then pskill would fail also.
Google for nt+vms. On the first page there is this link:
Windows NT and VMS: The Rest of the Story .
For example, this is the explanation of the 4 bugcheck parameters on the IRQL_NOT_LESS_OR_EQUAL blue screen:
The following parameters are displayed on the blue screen.
1 Memory referenced
2 IRQL at time of reference
3 0: Read 1: Write
4 Address which referenced memory
That's an interesting claim. Do you have any specific examples of this actually happening?
As far as I know, all IE code runs as the user which means exploits in IE can't automatically elevate to root.
I even went to the security bulletin search, searched for IE6 bugs and clicked on several at random. They all had this text:
If an attacker exploited these vulnerabilities, they would gain only the same privileges as the user.
So, again, where did you get this idea that IE bugs lead to root exploits?
Let's clarify the terminology. For the purposes of this discussion, let's say an "application" is a process running as the interactive user. It could be vulnerable to message attacks, but it wouldn't matter because it has the same privileges as the user.
A "service" is a process running as some privileged user. It could be a real service, or a COM+ application, or something like that.
An "interactive service" is a service that has taken the steps necessary to inject its UI into the interactive desktop.
So here's what we have:
There are in fact problems in Windows that could be called "fundamental" and difficult to fix. But this isn't one of them. It boils down to the fact that if you accept input from untrusted sources, you have to validate it. Validating all possible windows messages is hard, so the best solution is to not accept them in the first place, which means not having any UI in a service unless you know what you're doing.
Except that both processes have to be running on the same windowstation/desktop to be able to exchange messages. Thus the majority of services are not vulnerable to any of this - you have to *explicitly* configure your service to create any UI on the interactive desktop. People who understand how this works knew about the security implications of having interactive services long before the term "shatter attacks" appeared.
Thus, there is a pervasive and *unremovable* hole in Windows design.
It's not "pervasive" because by default services are not vulnerable. It's not "unremovable" because all known places where even interactive services could be exploited are fixed now. If you know otherwise, I'd like to see more details.
Not surprizing, actually, given the default permissions:
E:\cacls "Program Files"
e:\Program Files
BUILTIN\Users:R
BUILTIN\Users:(OI)(CI)(IO)(special access:)
GENERIC_READ
GENERIC_EXECUTE
Yes, this is the right way to contact the MS Security Response Center. This is what most people who actually find vulnerabilities do. And no, it's not better to email individual employees - they will just forward your email to MSSRC.
I think Sun was actually complaining about things like J/Direct which were making it too easy to write Windows programs in Java. Sun's solution (JNI) was purposefully complicated so that interoperability with native code was a pain in the ass.
It's not pointless. They don't store every crash dump, but the total number of crashes is recorded. Higher numbers mean higher chances of a fix. Of course, that's assuming that the app didn't wipe out its stack so the fault goes into some generic "we have no idea what's going on" bucket, and that all crashes are actually identical or similar enough, and that the problem is actually in Windows and not the app etc.
As for making the crash info available to 3rd party vendors - it already is. You can see the crash data for your applications if you participate in the "certified for windows" program or something like that.
One could argue that the first kind of patents can actually be useful, but patents on plugins in general are just crazy IMO.
ISVs can access error reporting data for their drivers and applications. See https://winqual.microsoft.com/moreInfo.aspx#WER for details.
Then you can use queued mode which doesn't require always-on connection. This is from the help for the error reporting settings dialog:
There is a huge difference between this and what a Palladium based system could potentially do. Software Restriction Policies in XP and Win2003 are not bulletproof. They can protect users from accidentally running a trojan/virus but they cannot guarantee that somebody hasn't modified the OS itself.
This is a fundamental problem with traditional (non-Palladium based) systems. OS can give you some protection but to guarantee the integrity of the OS itself you need some kind of hardware support.
MS has been working on Win2003 which is a major release supporting two architectures (x86 and IA64). Adding AMD64 support would have delayed it. Looks like they felt it was more important to release Win2003 sooner than to have AMD64 support sooner.
NT has been running on AMD64 for more than a year now. There's a difference between porting the kernel and releasing a fully tested product with major application support (Exchange, SQL etc).
So your theory is that Microsoft has been sitting on it's hands all these years without porting to any of the readily available 64-bit platforms? Including Itanic, which has been around in beta incarnations for several years?
Of course not. In fact, there are released Itanium versions of XP and Windows 2000. I heard that before that, there was an internal 64-bit Alpha version of Win2K.
Why do you think so? The following is a quote from a MS Press book ("Writing Secure Code"):
Security principles to live by:
What tool/program/technique do you use to determine this?
Oh come on. If you want to hear about perfmon and vadump, go to some M$ newsgroup or something.
This is Slashdot, and it's a well established fact around here that
Like many other features in Windows (such as 'disable command prompt' policy) Power Users exist for ease of administration, not for security. It can prevent users from shooting themselves in the foot but it will not stop a determined hacker.
On the other hand, BUILTIN\Users does represent real security boundary. There is no way a normal user can elevate himself to an admin.
I'd say it was a design goal for XP Home... Try explaining to a typical home user why half of his games don't work if he's not an administrator.