2012-04-16 6 views
12

Quindi ho un semplice esempio, dove ho l'app A, che ha alcuni cred di codice fisso per utente X, un amministratore locale, quindi avvia l'app B con quelle credenziali utilizzando un percorso assoluto codificato. Entrambe le applicazioni A e B e dotnet console, tuttavia non interagiscono con la console, basta solo scrivere le informazioni su un file.Windows ha una limitazione quando un processo avviato da un'attività pianificata sotto un gruppo di credenze esegue un altro programma sotto un diverso gruppo di crediti

quando ho eseguito un modo interattivo (sotto i miei creds, con un doppio clic, o tramite cmd.exe o una sessione di PowerShell interattivo funziona benissimo. Chiamando con successo B

quando l'eseguo attraverso un'attività pianificate con A essendo sotto da creds, e chiamando B con l'utente X il codice di errore del Process.Start (mystartinfo) è -1.073,741502 millions o 0xc0000142 in esadecimale che significa "l'applicazione non correttamente inizializzata"

Tuttavia, se si esegue il operazione pianificata chiamata A con credenziali utente X che funziona ..

Ho eseguito questo piccolo test principalmente perché vedo un comportamento simile quando provo a fare "start-job -Credential" in powershell da un'attività pianificata o remota, o chiamando start-process in powershell o System.Diagnostic> Process.Start da all'interno di PowerShell negli stessi scenari. All'inizio ho pensato che fosse un bug in PowerShell ma sembra essere più profondo .. Sia Windows o specificamente Dotnet e voglio sapere se questo è noto/documentato e se ci sono soluzioni alternative.

+0

Qualcosa di significativo nel registro del task scheduler? –

+0

no poiché il processo principale (quello che viene eseguito dall'attività pianificata) rileva e registra l'eccezione, l'utilità di pianificazione dell'attività registra solo un'esecuzione corretta. – klumsy

+0

Tiro totale al buio. So che le attività pianificate richiedono il "Accedi come lavoro batch", dal momento che è possibile eseguire direttamente A con l'utente X direttamente, non sono sicuro se questo si applica. http://msdn.microsoft.com/en-us/library/ms813942.aspx –

risposta

1

Ho riscontrato un comportamento simile in Windows Server 2008R2. L'applicazione My C# (A) avvia un processo B.

Il processo B non riesce a funzionare senza accesso al desktop di Windows, [non riesce a chiamare l'API di Windows CreateWindow();], che è impedito da eseguire quando funzionare come un servizio (o scheduler) (questo è quello di evitare che un noto escalation di privilegi utente tramite "in cmd.exe/interattivo")

vi consiglio di controllare l'ambiente che stanno usando e controllano se è lo stesso problema. In tal caso, è necessario cercare come rimuovere i riferimenti alla chiamata API CreateWindow() o gestirli correttamente.

Sfortunatamente, non ho avuto accesso al processo B e quindi non ho avuto successo nel risolvere questo problema. Ho finito per distribuire la soluzione su una macchina Server 2003.

+0

grazie, ne sono consapevole. Nel mio scenario del mondo reale è tutto su PowerShell V3 e script. ma nella mia prepro ho menzionato sopra, ho appena creato delle console molto semplici che non hanno creato nessuna finestra. – klumsy

1

in modo da avere un processo di A, che va da un'operazione pianificata (non interattivo), come si e lancia il processo B come X (admin locale) Chiarimenti:

  • Sei un admin su quella scatola?
  • B ha bisogno di una maniglia della finestra o di una maniglia della console?

È possibile provare a utilizzare ProcessMonitor per vedere quale chiamata ha esito negativo. La mia ipotesi è che B stia cercando di interagire con il desktop e viene negato il permesso di farlo.

Quando si effettua il login, come utente A, e si avvia un processo interattivo utilizzando l'utilità di pianificazione, la finestra si presenterà correttamente.Ma se sei loggato come utente B (ad esempio un utente ospite) e avvii un processo interattivo che funziona come A (ad esempio un amministratore locale), allora il sistema ha davvero un problema su cosa dovrebbe fare per mostrare l'interfaccia utente

Per riassumere, se si dispone di un processo interattivo che utilizza le credenziali dell'utente non connesso, non esiste un chiaro vincitore su quale sia la cosa giusta da fare.

1

Ok, questo post è piuttosto vecchio ma sto eseguendo lo stesso problema (il processo di avvio di PowerShell fallisce con il codice di uscita -1073741502 quando si esegue un servizio).
A quanto pare questo è legato a questo problema (Why is this process crashing as soon as it is launched?)

Process.Start chiama internamente CreateProcessWithLogonW (CPLW) quando vengono specificati credenziali. CreateProcessWithLogonW non può essere chiamato da un ambiente di servizio Windows (come un servizio WCF IIS). È possibile chiamare solo da un processo interattivo (un'applicazione avviata da un utente che ha effettuato l'accesso tramite CTRL-ALT-DELETE).

Suppongo che sia qualcosa di simile quando si esegue un'attività pianificata, viene eseguito in un ambiente di servizio Windows.
Probabilmente le chiamate native API che si stanno inducendo sono impedite per essere eseguite da un servizio.