Sinalizadores de criação de processo
Os sinalizadores de criação de processo a seguir são usados pelas funções CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW e CreateProcessWithTokenW . Eles podem ser especificados em qualquer combinação, exceto conforme observado.
Exemplo
BOOL creationResult;
creationResult = CreateProcess(
NULL, // No module name (use command line)
cmdLine, // Command line
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set handle inheritance to FALSE
NORMAL_PRIORITY_CLASS | CREATE_NEW_CONSOLE | CREATE_NEW_PROCESS_GROUP, // creation flags
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&startupInfo, // Pointer to STARTUPINFO structure
&processInformation); // Pointer to PROCESS_INFORMATION structure
Exemplo de exemplos clássicos do Windows no GitHub.
Flags
| Constante/valor | Descrição |
|---|---|
|
Os processos filho de um processo associado a um trabalho não estão associados ao trabalho. Se o processo de chamada não estiver associado a um trabalho, essa constante não terá efeito. Se o processo de chamada estiver associado a um trabalho, o trabalho deverá definir o limite de JOB_OBJECT_LIMIT_BREAKAWAY_OK . |
|
O novo processo não herda o modo de erro do processo de chamada. Em vez disso, o novo processo obtém o modo de erro padrão. Esse recurso é particularmente útil para aplicativos de shell multithread que são executados com erros rígidos desabilitados. O comportamento padrão é que o novo processo herda o modo de erro do chamador. Definir esse sinalizador altera esse comportamento padrão. |
|
O novo processo tem um novo console, em vez de herdar o console do pai (o padrão). Para obter mais informações, consulte Criação de um console. Esse sinalizador não pode ser usado com DETACHED_PROCESS. |
|
O novo processo é o processo raiz de um novo grupo de processos. O grupo de processos inclui todos os processos descendentes desse processo raiz. O identificador de processo do novo grupo de processos é o mesmo que o identificador de processo, que é retornado no parâmetro lpProcessInformation . Os grupos de processos são usados pela função GenerateConsoleCtrlEvent para habilitar o envio de um sinal CTRL+BREAK para um grupo de processos de console. Se esse sinalizador for especificado, os sinais CTRL+C serão desabilitados para todos os processos dentro do novo grupo de processos. Esse sinalizador será ignorado se especificado com CREATE_NEW_CONSOLE. |
|
O processo é um aplicativo de console que está sendo executado sem uma janela de console. Portanto, o identificador de console do aplicativo não está definido. Esse sinalizador será ignorado se o aplicativo não for um aplicativo de console ou se for usado com CREATE_NEW_CONSOLE ou DETACHED_PROCESS. |
|
O processo deve ser executado como um processo protegido. O sistema restringe o acesso a processos protegidos e aos threads de processos protegidos. Para obter mais informações sobre como os processos podem interagir com processos protegidos, consulte Direitos de Acesso e Segurança do Processo. Para ativar um processo protegido, o binário deve ter uma assinatura especial. Essa assinatura é fornecida pela Microsoft, mas não está disponível atualmente para binários que não são da Microsoft. Atualmente, há quatro processos protegidos: base de mídia, mecanismo de áudio, relatório de erros do Windows e sistema. Os componentes que são carregados nesses binários também devem ser assinados. As empresas multimídia podem aproveitar os dois primeiros processos protegidos. Para obter mais informações, consulte Visão geral do caminho de mídia protegida. Windows Server 2003 e Windows XP: Não há suporte para esse valor. |
|
Permite que o chamador execute um processo filho que ignora as restrições de processo que normalmente seriam aplicadas automaticamente ao processo. |
|
Esse sinalizador permite que processos seguros, executados no ambiente de segurança Virtualization-Based, sejam iniciados. |
|
Esse sinalizador só é válido ao iniciar um aplicativo baseado no Windows de 16 bits. Se definido, o novo processo será executado em uma VDM (Máquina virtual dos DOS) privada. Por padrão, todos os aplicativos baseados no Windows de 16 bits são executados como threads em uma única VDM compartilhada. A vantagem de executar separadamente é que uma falha encerra apenas a VDM única; quaisquer outros programas em execução em VDMs distintas continuam funcionando normalmente. Além disso, aplicativos baseados no Windows de 16 bits executados em VDMs separadas têm filas de entrada separadas. Isso significa que, se um aplicativo parar de responder momentaneamente, os aplicativos em VDMs separadas continuarão a receber entrada. A desvantagem de executar separadamente é que é preciso significativamente mais memória para fazê-lo. Você deverá usar esse sinalizador somente se o usuário solicitar que aplicativos de 16 bits sejam executados em sua própria VDM. |
|
O sinalizador só é válido ao iniciar um aplicativo baseado no Windows de 16 bits. Se a opção DefaultSeparateVDM na seção windows de WIN.INI for TRUE, esse sinalizador substituirá a opção. O novo processo é executado na Máquina Virtual dos DOS compartilhada. |
|
O thread primário do novo processo é criado em um estado suspenso e não é executado até que a função ResumeThread seja chamada. |
|
Se esse sinalizador for definido, o bloco de ambiente apontado por lpEnvironment usará caracteres Unicode. Caso contrário, o bloco de ambiente usa caracteres ANSI. |
|
O thread de chamada inicia e depura o novo processo. Ele pode receber todos os eventos de depuração relacionados usando a função WaitForDebugEvent . |
|
O thread de chamada inicia e depura o novo processo e todos os processos filho criados pelo novo processo. Ele pode receber todos os eventos de depuração relacionados usando a função WaitForDebugEvent . Um processo que usa DEBUG_PROCESS se torna a raiz de uma cadeia de depuração. Isso continuará até que outro processo na cadeia seja criado com DEBUG_PROCESS. Se esse sinalizador for combinado com DEBUG_ONLY_THIS_PROCESS, o chamador depura apenas o novo processo, não processos filho. |
|
Para processos de console, o novo processo não herda o console do pai (o padrão). O novo processo pode chamar a função AllocConsole posteriormente para criar um console. Para obter mais informações, consulte Criação de um console. Esse valor não pode ser usado com CREATE_NEW_CONSOLE. |
|
O processo é criado com informações de inicialização estendidas; o parâmetro lpStartupInfo especifica uma estrutura STARTUPINFOEX . Windows Server 2003 e Windows XP: Não há suporte para esse valor. |
|
O processo herda a afinidade de seu pai. Se o processo pai tiver threads em mais de um grupo de processadores, o novo processo herdará a afinidade relativa ao grupo de um grupo arbitrário em uso pelo pai. Windows Server 2008, Windows Vista, Windows Server 2003 e Windows XP: Não há suporte para esse valor. |
Comentários
No Windows de 32 bits, os aplicativos de 16 bits são simulados por ntvdm.exe, não executados como processos individuais. Portanto, os sinalizadores de criação do processo se aplicam a ntvdm.exe. Como ntvdm.exe persiste depois de executar o primeiro aplicativo de 16 bits, quando você inicia outro aplicativo de 16 bits, os novos sinalizadores de criação não são aplicados, exceto para CREATE_NEW_CONSOLE e CREATE_SEPARATE_WOW_VDM, que criam um novo ntvdm.exe.
Requisitos
| Requisito | Valor |
|---|---|
| Cliente mínimo com suporte |
Windows XP [somente aplicativos da área de trabalho] |
| Servidor mínimo com suporte |
Windows Server 2003 [somente aplicativos da área de trabalho] |
| Cabeçalho |
|
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de