|
Luc Pattyn wrote: It will not be an easy task though; I would not consider doing it if I can avoid it.
Lets just say i don't seem to have a choice  and i have to do it :@. Now how to go about it? 
Thanks.
|
|
|
|
|
Searching CP I stumbled on this article.[^] Maybe it could be useful to you?
|
|
|
|
|
Thanks alot, i guess this will work
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
