Je lance un processus Java ("Java.exe") de .net. En utilisant processus.start () . En plus du processus Java, un autre processus appelé
9 Réponses :
Pour être flagrant, je ne sais rien de Java, je ne peux donc pas vous aider avec # 1. Je peux vous aider avec # 2, cependant.
Pour le suivre avec .NET, vous pouvez utiliser System.Diagnostics. P>
Premièrement, vous devez d'abord obtenir chacun des processus par le nom "conhost.exe ", lancez Java, puis obtenez tous les processus à nouveau et comparez. P>
Pour obtenir les instances spécifiques, utilisez l'ID Process ID EM>: P> foreach (Process singleProcess in Process.GetProcessesByName("conhost"))
{
//Store the following in some kind of array
somePidArray[yourindex] = singleProcess.Id;
}
Je ne sais pas quel conhost.exe est à moi, parce que je ne le lance pas directement, je n'ai donc aucun moyen de comprendre quel PID est le mien.
Oui. Je déteste aussi que cela nécessite donc au moins 15 caractères dans des commentaires.
Mise à jour: i devinez que vous pouvez trouver le raisonnement sur l'ancien envoi . Il a probablement été ajouté pour restaurer certaines fonctionnalités (comme glisser-déposer) retirées de Windows Vista en raison de raisons de sécurité.
avant la mise à jour: Conhost semble lancer sur n'importe quelle ouverture cmd.exe. C'est probablement une nouvelle chose nouvelle, sans papiers sur Windows 7.
C'est un processus qui héberge la fenêtre de la console. Il a été introduit dans Windows 7 (IIRC), dans les anciennes versions, la fonctionnalité a été exécutée dans le cadre du processus CSRSS.EXE.
Dans les versions antérieures de Windows, les fenêtres de la console ont été hébergées dans CSRSS, qui est un processus critique système hautement privilégié, de confiance et de confiance. Sur Win7, il apparaît que les fenêtres de la console sont maintenant hébergées à Conhost.exe, qui a moins de droits. Cela a probablement été fait pour des raisons de sécurité et de fiabilité - un problème de sécurité dans le système de console ne compromettra pas toute la boîte, et un crash dans le code de la console n'aura pas d'écran bleu.
Voici quelques informations de base à ce sujet: blogs.technet.com/b/askperf/archive/2009/10/05/...
Venant de Unix, il est vraiment vraiment difficile de saisir l'idée de ce qu'ils essaient de faire avec cette chose. Je ne comprends pas ce que "hébergement" fait précisément pour l'entrée / sortie standard de base. Pourquoi chaque processus a-t-il besoin d'un processus de frère qui l'accueille? Semble inefficace. En outre, une fois que vous vous retrouvez avec l'un de ces nombreux processus de conhost, comment trouvez-vous sa raison d'être, quel autre processus il "héberge"? Actuellement, plusieurs dizaines de conhôtes mangeaient chacune 2,5% de la CPU, totalisant 100% de processeur et rendant le système dans un état inutilisable et je ne peux pas dire quelle est la raison.
Ceci soulève une question connexe: voulez-vous une fenêtre de console pour la demande Java engendrée par l'application .NET? Sinon, vous pouvez exécuter la commande javaw au lieu de java . Je ne l'ai pas expérimenté sur Vista, mais cela peut éliminer le processus conhost.exe .
Je veux une fenêtre de console parce que je lis sa sortie du côté .NET.
Je viens d'écrire un article tenter d'expliquer le but du processus. Il est orienté vers des personnes régulières, mais il y a beaucoup de captures d'écran pour illustrer.
Qu'est-ce que c'est conhost.exe et pourquoi est-il en cours d'exécution?
La ligne inférieure est que Conhost.exe est assis entre le processus CSRSS et CMD.exe, de sorte que vous puissiez utiliser à nouveau glisser-déposer.
Désolé, pour Necroing un si vieux fil, mais je pensais que la question est intéressante et mérite une réponse.
Pourquoi conhost.exe est-il alors lancé?
Comme expliqué dans d'autres messages, il s'agit maintenant d'une manière par défaut d'héberger les applications de console. Vous trouverez d'autres détails dans l'article lié à une autre réponse ici: Qu'est-ce que conhost.exe et pourquoi est-ce qu'il marche? comme autre a noté Il devrait y avoir peu de raisons de "suivre" le processus de la Conhost. Cela dit, il existe un moyen d'obtenir un identifiant de processus de conhost à partir de votre identifiant de processus Java.exe. Tout ce que vous avez à faire est d'énumérer toutes les poignées de processus que chaque processus de conhost dans le système a, et si l'une de ces poignées pointe vers un processus avec le même identifiant que votre Jawa.exe, ce sera la poignée conhost.exe que vous êtes après. Cachez-la pour traiter ID et vous obtenez le PID pour Conhost.exe Donc c'est la théorie. Comment y parvenir dans la pratique? Il y a un Excellent article que montre un certain code qui fait quelque chose de très similaire. J'ai modifié ce code un peu pour convenir à notre tâche à la main. À la fin, vous et maintenant le code: note, que j'ai uniquement testé ce code sur X64 Windows 7 avec X86 et option de compilation x64. Je l'ai compilée avec VS2010 pour .NET 4. Ce code est inférieur à lisible et je ne peux pas vous garantir qu'elle fonctionne sur toutes les plateformes et toutes les architectures pertinentes. Cependant, cela fonctionne ici (TM) et est utile pour cette tâche ésotérique. UTILITY.GETCONHOSTIDBYPROCESSID Fonction statique et passez le PID de votre Java.exe à celui-ci, et il vous retournera le PID de Conhost.exe pertinent un appel de test à cette méthode peut être trouvé dans cette méthode. La fonction principale de l'exemple ci-dessous.
Pour WinXP + Il est préférable d'utiliser System_extensed_handle_Information depuis que system_handle_information ne renvoie que le processus de processus long de 16 bits ID-S. Si le système est fortement chargé avec des poignées, le processus ID-S a tendance à commencer à avoir des valeurs supérieures à 65K, par exemple 8 chiffres décimaux. Le système a appelé que le code ci-dessus utilise simplement masquer les fortes bits de processus de processus. Vous pouvez trouver System_handle_Table_entry_info_ex et son utilisation dans le code source du pirate de traitement. Lorsque j'ai le temps de passer du temps, je publierai mon propre code C # mis à jour basé sur la vôtre, avec quelques bugs logiques et des fuites fixes. - Merci beaucoup pour votre code!
S'il vous plaît vérifier ma mise à jour effectuée sur 27.06.2014. Il s'agit de l'emballage et de la lecture de la structure Unicode_string sous 64 bits, ce qui ne va pas pour le code ci-dessus. Veuillez vous reporter à Stackoverflow.com/a/19871391/193017
Quand on lance un processus à l'aide de 'process.start ()', on a la possibilité de créer directement le processus ou de lancer "cmd.exe" et de laisser "cmd.exe" gérer les détails. Le drapeau "useshelexecute" contrôle ceci. Si vous choisissez de laisser les détails à «cmd.exe», ce qui est courant dans des situations où vous souhaitez appeler un fichier et laissez la coquille exécuter le programme approprié pour le gérer, par exemple. En "exécutant" un fichier '.txt', alors sur Win7, cela fonctionnera en réalité 'cmd', qui fonctionne lui-même "Conhost". Si, d'autre part, vous n'utilisez pas 'Shellexecute' puis 'Start ()' ne fonctionnera pas 'cmd' et vous ne lancerez pas indirectement "conhost".
Je vois le contraire; Je lance avec userShelexecute = false et je reçois un conhost ...
Basé sur ZESPRI STRAND> La réponse J'ai écrit des méthodes mises à jour.
Plus d'explication pour la méthode mises à jour:
Ce code est capable de gérer le processus ID-S plus de 16 bits.
également un bogue logique a été corrigé et quelques fuites de mémoire et de poignée. Ajouté des obstacles.
J'ai ajouté une méthode pour cas lorsque CONHOST.EXE dispose de plusieurs processus associés. Cela peut arriver lorsqu'il y a un programme de console exécutant et comporte CMD.exe comme processus parent, mais également d'autres cas, où les processus associés ne sont même pas liés à la relation entre enfants.
Merci beaucoup pour zespri strong> pour le code d'origine, il y a beaucoup à apprendre de celui-ci!
Pour WinXP + Il est préférable d'utiliser System_extenced_handle_Information depuis que system_handle_information ne renvoie que le processus de processus long de 16 bits ID-S. Si le système est fortement chargé avec des poignées, le processus ID-S a tendance à commencer à avoir des valeurs supérieures à 65K, par exemple 8 chiffres décimaux. Le système a appelé que le code ci-dessus utilise simplement masquer les fortes bits de processus de processus. Vous pouvez trouver System_handle_Table_entry_info_ex et son utilisation dans le code source du pirate de traitement. P> [StructLayout(LayoutKind.Sequential)] //, Pack = 1)] //NB! no packing!
public struct UNICODE_STRING
//IntPtr ipTemp = Is64Bits() ? new IntPtr(Convert.ToInt64(objObjectType.Name.Buffer.ToString(), 10) >> 32) : objObjectType.Name.Buffer;
//string strObjectTypeName = Marshal.PtrToStringUni(ipTemp, objObjectType.Name.Length >> 1);
string strObjectTypeName = Marshal.PtrToStringUni(objObjectType.Name.Buffer, objObjectType.Name.Length >> 1);
pas sûr à 100%, bien sûr l'exactitude de ce que je suis sur le point de dire, mais d'après ce que je pouvais lire la conhost, c'est actuellement héberger l'invite de commande dans Windows Seven, il commence à tout processus.Start () ... Je me demande pourquoi ça reste après la Le processus est tué ... et pourquoi diable empêcherait-il de supprimer le dossier. Personnellement, si c'est vraiment votre problème, je suggérerais de faire du piratage et de tuer le processus que vous devriez certainement essayer tout le reste que vous puissiez avant d'essayer cela (SRY pour les fautes de frappe, im Français faisant de mon mieux pour taper: p)
Pourquoi voudriez-vous le suivre?