|
Can anyone show me a way to get system cpu usage from a batch file and return it as a percentage so I can display it in an HMI software package?
Thanks
|
|
|
|
|
You might try WMI[^]
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
We are trying to get an interactive command prompt,running with 'SYSTEM' user credentials
The sequence of steps are as follows:
1) Get the local time (through the TIME shell command, for example)
2) Add one minute to this time
3) Run the AT command with this new time.
4) Wait one minute for the command window to appear.
An example set is as below:
E:\Documents and Settings\Adi>time
The current time is: *16:29*:00.96
Enter the new time:
E:\Documents and Settings\Adi>at *16:30* /interactive cmd.exe
Added a new job with job ID = 1
We do get a command prompt with 'SYSTEM' privileges.
Next,we attempt to do this on a remote w2003 host through REMOTE login.
In this case,though we find the cmd.exe running in the task manager,we DO NOT see the command prompt in the foreground.
What service/security setting prevents the command prompt to interact with the desktop in this case?
We also confirmed that in certain other environments ,we do see the command prompt on the foreground ,even via remote login.
Unfortunately,we have not been able to work out the security 'tweak',which obstructs our first environment from doing so.
Any help will be much appreciated.
|
|
|
|
|
rana74 wrote: What service/security setting prevents the command prompt to interact with the desktop in this case?
Everything. Because of the MASSIVE security risk, interactive processes are not allowed to be visible when launched on remote systems.
|
|
|
|
|
Well this definitely does not seem to be the case for all hosts - as we have this 'interactivity' working even for remote login into most of our w2003 host environments,where we have out-of-box security settings.
So,there is some security switch which 'hardens' this property - as we see in some other environments.
We are eager to find out what that 'switch' is.
|
|
|
|
|
rana74 wrote: Well this definitely does not seem to be the case for all hosts - as we have this 'interactivity' working even for remote login into most of our w2003 host environments,where we have out-of-box security settings.
Not out of the box you don't. Unless you're using a third party tool that does this to get around the limitation, like PSEXEC. Using the Win32 API, you cannot launch an interactive remote process and there is no "switch" to get around it.
|
|
|
|
|
It's very straightforward: 'interactive' services display in session 0, the 'console' session. This is the session you see when you log on on the physical keyboard/mouse/screen (or emulation of it, if you're using a virtual machine).
Normally, a remote connection with Remote Desktop (Terminal Services Client) to a Windows Server OS gives you a new session. Windows Server 2003 allows you to connect to the console session by passing the /console switch to mstsc. You can also specify '/console' after the computer name in the connection dialog. This feature is only supported in Windows Server 2003; Windows 2000 ignores the setting.
Other 'remote desktop' tools like VNC and LogMeIn actually give you the console session.
Windows Vista and Windows Server 2008 have 'session 0 lockdown' - users log on to session 1 and above, even if logging on at the physical computer. UI created by 'interactive' services is not shown - session 0 is now only used to allow interactive services to communicate with each other. See Impact of Session 0 Isolation on Services and Drivers in Windows Vista[^].
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
On Windows XP, I've observed that modifying in-memory code in system DLL's only affects the current process. Does the same hold true on all versions of Windows from Windows 95 to the present?
|
|
|
|
|
zildjohn01 wrote: On Windows XP, I've observed that modifying in-memory code in system DLL's only affects the current process. Does the same hold true on all versions of Windows from Windows 95 to the present?
Yes. Each process gets it's own copy of the operating system environment.
|
|
|
|
|
In Win 9x, all memory from 0x80000000-0xFFFFFFFF is shared and writable to all processes. System DLLs (and other interesting bits like shared memory sections) reside there. This is not the case on NT-based OSes.
|
|
|
|
|
Is there some way to modify the Internet Explorer security settings for the 'LocalSystem' account.
'Local System' account is the user under which all windows services run by default.
We need to achieve this either programmatically or through edit of registry settings.
Internet security privileges for the 'LocalSystem' account (like allowign download of unsigned activex controls) cannot be modified from the browser.,unlike an interactive user.
We also do not have the option to launch the browser programmatically by impersonatign as this user.
|
|
|
|
|
There is a tool "Terminal Service Manger" available in Windows 2k3, does anyone know is there in any tool available in Windows XP like "Terminal Service Manger".
Note: By mistake I have put this question in "General Discussion" Forum, so putting it at this forum and removing it from that forum.
Thanks,
Mushq
|
|
|
|
|
That would be the Remote Desktop
See here for more info[^]
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
Is there any way to do this?
I know you can snapshot the files over, but is there anyway to make it bootable and start its installation procedures?
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
Probably not without access to the tool that was used to create the partition in the first place.
Cheers,
Sebastian
--
"If it was two men, the non-driver would have challenged the driver to simply crash through the gates. The macho image thing, you know." - Marc Clifton
|
|
|
|
|
It pretty simple, it is a bare min. bootable XP partition, with a secondary executable that does the recovery work.
I can't use F10 to boot into the recovery console, but I can run the secondary executable fine with a BartPE disk
I am not afraid of a little nitty Grity work, and the entire partition could fit on a single DVD, I just don't know how to get the Bootloader Code to form a bootable iso image.
Any clue there?
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
Well, in that case, you'll have to master your own WinPE disk (like BartPE) and include the secondary image.
HOWEVER, there is one caveat: If the recovery tool recovers not only the system partition, but the partition table as well, you'll lose any data stored in the former "recovery partition" and more so if you repartitioned the disk.
If I was you, I'd backup my data, do one "recovery", then use Norton Ghost to image the freshly installed system and thus create your own "recovery media".
Everything else seems to much of a hassle...
Cheers,
Sebastian
--
"If it was two men, the non-driver would have challenged the driver to simply crash through the gates. The macho image thing, you know." - Marc Clifton
|
|
|
|
|
I see... It does recover the partition table...
That sounds like my best choice (NG) as of now, thank you
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
I have a strange problem that shows up after I install our software. By "our software" I mean one of my company's products. I'll try to keep this short enough to read and will happily supply any further details.
The product is written in C# targeting .NET 2.0. It consists of three components. Two are installed as Windows services, the third is a WinForm based GUI. Only one of the services is involved in the problem, hereafter referred to as the "Server." The GUI application is the other involved, hereafter referred to as the "Client."
Both the Client and the Server need to use a third party native DLL, which is installed in the System directory (C:\WINDOWS\system32.) We are hoping to use Windows .msi installer packages, which I'm producing using VS2005. The installers register the DLL mentioned as "vsdrfCOMSelfReg" and that seems to work.
The problem comes in if we install both the Server and the Client on the same computer. Normally our customers will have one Server installed and multiple Clients on different machines as you would expect. However it's possible, even likely, that someone will install a Client on the Server machine. That causes the Server to lose its ability to perform the function for which it uses the DLL.
In our previous versions of this product, we used installers built by another tool, Setup Factory 7.0 from Indigo Rose. I have found that if I use SF7 installer for the Client, I don't have the problem. That's our interim solution until I figure out what's the problem with the .msi installer.
Here's what I've tried so far. Remove all components of this product from the machine, and delete anything left behind by the uninstallers (Registry entries, log files, etc.) Take a snapshot of the file system and of the HKLM Registry hive. Run a Client installer. Take another snapshot of the file system and of the HKLM Registry hive. Compare these snapshots to see what files are installed and what's added to the Registry. Remove Client and clean up after uninstall. Repeat procedure with the other Client installer. Compare results from each type of installer.
The SF7 installer puts some files it uses for uninstalling in the installation directory and in C:\WINDOWS. Other than that, no difference. The .msi installer puts a whole bunch of stuff about itself in the Registry. Both install all the expected files and make the same Registry entries regarding registering the DLL.
At long last, the questions:
Any ideas what might be causing this?
What else should I try in order to find the problem?
Any suggestions for work-arounds or solutions?
Why a duck?
BDF
A learned fool is more a fool than an ignorant fool.
-- Moliere
|
|
|
|
|
Have you enabled MSI logging? if not, read how to http://support.microsoft.com/kb/223300[^] then investigate the resulting log files.
Use Systems Internals Process Monitor (or RegMon + FileMon) to record activity at installation and look for any Access Denied and investigate those.
Keep us posted on your progress
modified 1-Aug-19 21:02pm.
|
|
|
|
|
I'll try the MSI logging. I've got Process Monitor, I'll need to look at it more closely to see how to accomplish what you describe.
So far I've not seen anything missing in either the files or Registry, as I assume would be the case if an Access Denied situation arose.
Thank you for the reply, I'll get busy with your suggestions. 
BDF
A learned fool is more a fool than an ignorant fool.
-- Moliere
|
|
|
|
|
After you have created the MSI file, you could use this utility to look at the contents of the MSI to establish if the MSI file has expected contents etc.
Less MSIérables[^]
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Thanks for the link. I downloaded and used it. Didn't find anything other than what I expected to be in the MSI package. It will be a handy tool to have around. Need to make time to look at the source code.
Today I ran the installer with logging on and Process Monitor running. Examined the log file and the Process Monitor data but did not find any errors of note or anything else relevant to the problem.
However Mike Dimmick posted a reply that I believe contains the answer and some possible solutions. It's quite detailed if you're interested. It turns out that two MSI installers installing the same DLL in the same directory is not as straightforward an operation as I had expected.
Thanks again for your help. I learned a lot from the exercise.
BDF
A learned fool is more a fool than an ignorant fool.
-- Moliere
|
|
|
|
|
I looked at Mike's reply, and his MVP status is well earned, and in these forums, his replies are always most excellent. Anyhow, as long as my replies did not push you down unnecessary blind alleys
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Right, I think your problem here is most likely to be that the file has different GUIDs in the different installers.
Windows Installer tracks 'components', not files. It determines whether a component is installed or not by checking the KeyPath of the component - this is the file, registry key, directory or ODBC data source which it uses to determine whether the component is up to date. Visual Studio generates one component per file or registry key.
You can get into serious trouble if the same file is referenced by more than one component GUID on the machine. For each component installed by a product, Windows Installer remembers the key path that the component was installed to. When the number of references for a component in a given location drops to zero (the actual references are recorded, not the count, so it's more like GC than reference counting), all the resources for that component are removed, even if another component is still referencing the resource.
To avoid this problem, you must either: install the component privately, or if that isn't possible, ensure that the same GUID is used in both products.
I believe the only way to get VS to do this is to build a merge module containing the shared component, and consume that merge module in both installers.
Now for some more fun: although you've told it to self-register at install time, Visual Studio also tries to extract the registry information at install package build time, and uses the extracted data to populate the Class table[^] and the other associate COM tables. This causes Windows Installer to generate special registry entries when installing the class, an extra load of gibberish in a REG_MULTI_SZ value called LocalServer32 in the LocalServer32 key. This data tells Windows to give Windows Installer control when the object is created; Windows Installer checks whether the component is installed and if it needs to be repaired. If so you'll get a repair dialog. If the version numbers are different between client and server, this may happen; if it can't find the original installer, it may prompt for source.
Again, I think this can be reduced by ensuring the GUIDs are the same.
If you don't need to support Windows Installer's enterprise features, it may be easier all around if you use a tool that does not build Windows Installer databases. It's much much harder to make an MSI that works properly when deployed through Group Policy/Active Directory anyway.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
