Windows event logs are different at below Vista (XP and below) and Vista and up, see here Windows Event Logs . On Vista and up, on the event viewer, we could see a column called Level. If we filter the event, it would show us all the possible levels:
Critical
Warning
Verbose
Error
Information
The value of Information has value 4 based on my testing. However if we look at the schema for Level, actually the range of its values are not restricted. So here are two of my questions:
how do I know what value each of above string would have? Is there a page at MSDN for this? I could not find it
Is there any restriction for the Level or not? Or is it up to the Event provider itself?
I hope this link will help you.
As you can see from link above, custom levels values must be in range from 16 to 255, that's mean, that windows levels are placed in range from 0 to 15.
Related
Using the Android Management API, I would like to identify if a device has been rooted.
I found the attribute "devicePosture" and the possible values for this attribute are listed in this documentation here.
However, for me, it was not clear what these items mean.
For example:
Does the type "POTENTIALLY_COMPROMISED" mean that the device is rooted or just had its bootloader unlocked?
Does the "AT_RISK" type mean that you have a virus version of android (or something similar)?
Thank you for your help.
You can check this link , Also to answer some of your questions with regards to device posture.
The value of the security posture determines the current device state and the policies applied. Or in other terms it reflects how secure the device is
1.) “POTENTIALLY_COMPROMISED” value means that either SafetyNet's ctsProfileMatch check or basicIntegrity check fail or this device may be compromised and corporate data may be accessible to unauthorized actors. It covers both bootloader unlocked and rooted scenarios[1].
2.) "AT_RISK” value means that both SafetyNet's ctsProfileMatch check and basicIntegrity check pass but fails to meet requirements set by the policy (e.g. device's password state, etc.).
To determine whether what fails you can check the PostureDetail, SecurityRisk Value
[1] To understand what SafetyNet's ctsProfileMatch and basicIntegrity fields mean, you can check this link, which also explains what scenarios correspond to the combination of the value of the two checks.
I have a software activation logic which relies on thre parameters:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate
Id of system volume
I'm interested in question: could these parameters ever change under any conditions except manual modification of registry values (for 1, 2) in single OS installation?
System volume id, as far as i know, can change only when the volume is formated.
Both DigitalProductId and InstalLDate also should be constant in single OS as they identify a license (concrete windows installation) and the date the OS was initially installes respectively. So according to this logic they shouldn't ever change.
I want to find any documentation that proves these points. Unfortunately my searching for such a documentation didn't give me enough as all that i've found are articles like this http://technet.microsoft.com/en-us/library/cc709644(v=ws.10).aspx which contain inderect information on the topic.
Also i've looked through this great post: http://siginetsoftware.com/forum/showthread.php?596-Investigating-the-Microsoft-Digital-ProductID-(DPID)
It partially proves my points but doesn't give a 100% guarantee
I repeat a question here once again:
Could parameters 1-3 ever change in single Windows installation?
Thanks in advance
My research has shown that independently of windows updates, service packs and other software, these keys remain the same.
MSDN advises that RegisterWindowMessage() function is only used for registering messages to be sent between the processes. If a message is needed for sending within one process it can be safely selected from the range WM_APP through 0xBFFF.
However in our codebase I often see that RegisterWindowMessage() is used for messages only sent within one process. I suppose that this was done because of perceived simplicity of using RegisterWindowMessage() since it doesn't require manually distributing the message identifiers in the WM_APP..0xBFFF range.
Do I understand correctly that if many applications are run on one machine and they all call RegisterWindowMessage() with different strings they could exhaust the range of message identifiers allowed to return by RegisterWindowMessage() and for some of them it will just return a value indicating a failure? What could be a valid reason for using RegisterWindowMessage() messages in cases where WM_APP..0xBFFF range messages would suffice?
IMHO there is no valid reason to use RegisterWindowMessage if you are only sending messages to yourself
There is no (documented) way to un-register a message, so after your app quits, that registered message will stay in the atom table until reboot/logoff (I can't remember exactly where this atom table is stored, the window station or terminal server session instance probably)
The reason you need to use RegisterWindowMessage even when messaging to yourself is that it protects you from the idiot who broadcasts messages in the WM_APP + N range.
Yes, this does happen.
Abusing RegisterWindowMessage can potentially make a windows box unusuable. This is especially true if the window message names are dynamically generated and a bug causes out of control windows message allocation. In this case the global atom table in your windows station/ desktop will fill up and any process using User32.dll (basically, any app) will fail to start, create windows, etc.
There is a bug out there in Delphi / Borland products that registers messages that start with ControlOfsXXXXXX where XXXX is a memory address (or other dynamic modifier). Apps that are started and stopped frequently will register multiple ControlOfsXXXX atoms and eventually exhaust atom space. For more details see:
http://blogs.msdn.com/b/ntdebugging/archive/2012/01/31/identifying-global-atom-table-leaks.aspx
And
https://forums.embarcadero.com/thread.jspa?threadID=47678
A possible advantage is that Spy++ can display more informative text, therefore debugging is a bit easier. Compare
<00058> 00330CA2 S message:0x0419 [User-defined:WM_USER+25] wParam:00000000 lParam:00000000
with
<00129> 004F0DA0 S message:0xC2B0 [Registered:"AFX_WM_ONCHANGE_ACTIVE_TAB"] wParam:00000001 lParam:02B596E8
Of course, in principle there is a chance to run out of message IDs. On the other hand, in the source code of the MFC Feature Pack there are 52 calls to RegisterWindowMessage. So there are still 16300 IDs left for other applications.
What is the best way to determine how many window handles an application is using? Is there a tool or a WMI performance counter that I could use?
I would like to run up an app and watch a counter of some sort and see that the number of window handles is increasing.
for (int i=0; i < 1000; i++)
{
System.Threading.Thread.Sleep(1000);
RichTextBox rt = new RichTextBox();
rt.Text = "hi";
this.Controls.Add(rt);
}
I am running the above code and watching the "Handle Count" counter on the process, and it does not seem to be increasing. Is there something I am looking at incorrectly?
Perfmon, which comes with your computer can do it. You can also add a column to your task manager processes tab (Handle Count).
Instructions for Perfmon
Add a counter (click the +)
Choose Process under Performance object
Choose Handle Count under the counter list
Choose your process from the instance list
Click Add, click Close
To get the graph in range, you have to right-click it in the list, choose properties, and then choose the right scale (.1 or .01 would probably be right)
Edit (in response to added information): I think you just proved that creating RichTextBoxes doesn't result in Handles being allocated. I don't think it really needs one until you are editing the control and it might be smart enough to do that, since allocating too many resources for a control that isn't active would make it hard to have a lot of controls on a form (think about Excel, for example).
Process Monitor is very handy in interactively monitoring all sorts of resources used by Windows processes.
Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity.
Note - if you mean finding the information programatically, .Net provides access to all performance counters. You use the System.Diagnostics.PerformanceCounter Class like this:
PerformanceCounter PC=new PerformanceCounter();
PC.CategoryName="Process";
PC.CounterName="Handles";
PC.InstanceName="MyProc";
MessageBox.Show(PC.NextValue().ToString());
The handle count shown by taskmanager is the same as the one shown by PerfMon
ProcessExplorer tool from sysinternals can list the different type of handles + their names a process uses and you can get a good idea by browsing that list about the composition of the handles your program uses.
But I'm afraid it does not sumarize these handle type counts for you.
To view the actual handles and their types using ProcessExplorer - View - show lower pane view - handles.
You can also use some sort window spy tool which shows all the windows in the system like Microsoft spy++ or Managed Spy++ (http://msdn.microsoft.com/en-us/magazine/cc163617.aspx)
This will allow you to see if your windows are being created.
Perfmon or Task Manager cannot give you the number of WINDOW handles used by a process only the total number of handles of all types (file, thread, etc.).
The best information that I can find on the subject is this post which indicates that the window handle count for a process can be determined by enumerating all child windows of the main process window.
I'm looking for advanced strategies for dealing with User Object Handle limits when building heavy-weight windows interfaces. Please explain how you overcame or bypassed this issue using SWT or direct Windows GUI APIs. The only thing I am not interested in is strategies to optimize widget usage as I have done this extensively and it does not solve the problem, only makes it less likely.
My Situation:
I have an SWT based GUI that allows for multiple sessions within the same parent shell and within each session their are 3 separate places where a list of user generated comments are displayed. As a user opens multiple sessions and pulls data that populates those lists, the number of user object handles can increase dramatically depending on the number of comments.
My current solutions:
1. I page the comments by default thereby limiting the number of comment rows in each session, but due to management demands, i also have what is effectively a "View All" button which bypasses this completely.
2. I custom draw all non-editable information in each row. This means each row utilizes only 2 object handles.
3. I created JNI calls which query the OS for the current usage and the Max usage. With this i can give indications to users that a crash is imminent. Needless to say, they ignore this warning.
First off, are you sure the problem isn't desktop heap vs. handle count? Each handle can consume a certain amount of Windows desktop heap. One USER handle may eat a lot of space, some very little. I'm suggesting this to make sure you're not chasing user handle counts when it's really something else. (google for Microsoft's dheapmon tool, it may help)
I've read that you can alter the maxes on handles by changing keys in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\Windows\ USERProcessHandleQuota and GDIProcessHandleQuota
This could be a short term fix for users.
I'd approach this by first figuring out what 2 user handles need to be maintained for each item (like 2 for each item in a listbox?). This seems suspect. User handles are for only a few top-level Windows UI objects (Windows, menus, cursors, Window positions, icons, etc...). I don't see why your widget needs to keep 2 objects around for each item (is it an icon handle??).
If you're looking to rip the whole thing apart - this sounds like a job for a virtual-mode List-View (LVS_OWNERDATA).
You should think about using windowless controls. They are designed for precisely this situation. See "Windowless controls are not magic", by Raymond Chen
Not only top-level windows, but most native controls use one user object each. See Give Me a Handle, and I'll Show You an Object for an in-depth explanation of user- and other handle types. This also means that SWT uses at least one user handle per widget, even for a Composite.
If you truly are hitting the limit of 10000 user objects per process, and you don't have a leak, then your only option is to reduce the number of widget instances in your application. I wrote a blog article about how we did this for our application.