I have a Windows service (under WinXP SP2), running under the LocalSystem account, that launches processes using CreateProcessWithLogonW. In order to clean up child processes, I'm trying to use a job object and TerminateJobObject.
MSDN states that the job handle must have JOB_OBJECT_ASSIGN_PROCESS access right, which it has since it's created via CreateJobObject. The process handle must have PROCESS_SET_QUOTA and PROCESS_TERMINATE rights. I think it has them since TerminateProcess and SetProcessWorkingSetSize both return with no error.
Though, AssignProcessToJobObject fails with errno 5 (Access denied). Everything works fine if I replace CreateProcessWithLogonW with a simple CreateProcess.
Am I missing something or is what I'm trying to do impossible ?
Edit: It seems that svchost.exe, which actually creates the process when CreateProcessWithLogonW is used, already assigns the process to an anonymous job. The CREATE_CREAKAWAY_FROM_JOB flag is ignored by this function. So the real question is: is there a way to prevent svnhost from assigning the process to a job ?
From Jeff Lawson on MSDN:
Interactions with Win32 Job Objects
CreateProcessWithLogonW executes the
new process as a child of the
Secondary Logon service, which has the
outcome of making the process escape
any Job Object membership/restrictions
even if the Job Object did not allow
breakaway.
Furthermore, the Secondary
Logon service automatically creates
its own new Job Object and assigns the
new process into it. As such, it is
not possible for the caller to
explicitly assign the new process to
any other Job Object (since a process
may only be assigned to one Job
Object, and can never be removed from
a Job Object once it has been assigned
to one).
Does each new process need a different logon? Otherwise, you could create a single process with the new logon and have it spawn new process using CreateProcess that could then be associated with a Job Object.
we can enable privilege and use CreateProcessAsUserW instead
Related
Having spent the last several days converting a working frontend application for a database with Async/Await, I fear I have worked myself into a corner. Being new to all this, I have a very simple question.
What happens to an "awaiting" process when the computer is suspended? Additionally, can a process that is "awaiting" be detected in a generic fashion so that the user can be warned that "the process is not finished" prior to Window closure? (The application has many Create and Update processes to manage the database backend).
TIA
Instead of
await DoAsync();
you could do something like
task = DoAsync();
await task;
and when closing your application, you might want to check somewhere else
if(task.Status == TaskStatus.Running)
...
this would make sense for long running operations. Have a look at the Task Class, though.
System.Diagnostics.Process.Start(#C"\mydomain\mysubdomain\testdb\
app_DATA\DATAESCEL.exe);
This method has been called for insert excel sheets value into database. In main method I have write query fro save excel sheet values into database. Please help me how will I get return type value from above method?
This method returns a Process object.
Since you are creating another process from your main application, this process is main's child. However, communication between processes, yet trivial, may complicate your solution (you can search interprocess communication samples in the web).
If you simply want to know if your child process have succeeded, you can test its exit code (any value different from 0 indicates error).
Still, you could simply move this Excel structure to a DLL project and call it, say, as a thread. You would gain both in performance and simplicity.
I'm developing a simple win32 application with two processes sharing memory through a file mapping. At a certain point in the second process, I want to check if the other process has already closed the handle associated to the file mapping.
Is there a Windows function to retrieve the number of handles associated to my shared memory???
Thanks in advance for any help...
There's nothing in the API to do that. If you want to know when the other process has finished its work, create a manual reset event with CreateEventEx, and have the other process set the event when its work is done. The first process can use one of the wait functions to query the status of the event.
This is a question which follows on from my previously answered question here
At first I assumed I had a problem with the way I was creating my events due to the handles for OpenEvent returning NULL, I have managed to find the real cause however I am not sure how to go about it.
Basically I use Visual Studio to launch both Process A and B at the same time, in the past my OpenEvent handle wouldn't work due to Process A looking for the address of the event a fraction of a second before Process B had time to make it.
My solution was to simply allow Process B to run before Process A, fixing the error.
The problem I have now is that Process B now reads events from Process A and as you expect it too returns a null handle when trying to open the events from Process A.
I am creating the events in WM_CREATE message of both processes, furthermore I also create a thread at the same time to open/read/act upon the events.
It seems if I run them at the same time they don't get chance to see each other, alternatively if I run one before the other one of them misses out and can't open a Handle.
Can anyone suggest a solution?
Thanks.
Just replace OpenEvent with CreateEvent. CreateEvent will open an Event instead of creating a new one it finds an existing event with the name passed to CreateEvent.
I am working through the requirement to make a WPF Application single instance only.
However - I have to pass the command line to the first instance and then perform some UI action.
I am using a Mutext to check for already running instances, I do use NamedPipes to transfer the command line to the already running instance.
But of course I am not in the correct Thread to access "Window1".
I tried to store a reference to "Window1" in a static class and then use the Dispatcher to call a Method in "Window1", however, as soon as I try to access a variable (class wide scope in "Window1") I receive a "Object reference not set to an instance of an object."
The UI Action is to add a new Tab to a TabControl - during initialization of the new Tab some work is done - and the variables are initialized and even the method I want to call works during the init - but when called from the Dispatcher it fails.
Any hints, how to do this? Am I on the wrong track here?
Thanks!
This is easy:
void ProcessCommandLine(string commandLine)
{
Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() =>
{
... code to process the command line here ...
});
}
You can call this from your App.Startup and also from your thread that receives messages from the named pipe.
The key considerations here are:
Use of BeginInvoke instead of Invoke to prevent the calling thread from waiting
Use of DispatcherPriority.ApplicationIdle to guarantee the application has finished initializing before the command line is processed
Use of Application.Current.Dispatcher instead of Window1.Dispatcher in case Window1 has not yet been initialzed
That's not right, are you certain that the mutex is passing control correctly to your currently running instance of the application?
If it was a thread UI access issue, you should have received this error: The calling thread cannot access this object because a different thread owns it.
The fact that you're getting an "Object reference not set to an instance of an object." error message means that you've not yet instantiated the object as new.