04.06.2025
3907
37
0Cmd.exe an Windows-11-Taskleiste anheften
Hallo!
Ich musste leider kürzlich von Windows 10 auf 11 umsteigen. Jetzt nervt mich ein merkwürdiges Verhalten. Wenn ich die Befehlszeile übers Startmenü mit CMD.EXE aufrufe und dann über das Kontextmenü des Taskbuttons an der Taskleiste anhefte, erscheint beim nächsten Klick darauf nicht CMD.EXE sondern PS.EXE - also die Power Shell. Die aber will und brauche ich nicht.
Ich habe mir dann erstmal damit geholfen, dass ich manuell eine Verknüpfung zu CMD.EXE auf dem Desktop erstellt und in die Taskleiste gezogen habe. Das aber ist nicht gleichbedeutend mit einem angehefteten Programm, denn wenn man darüber ein DOS-Fenster öffnet, hat man den Eintrag doppelt in der Taskleiste (einmal den vom aktiven Fenster und dann noch mal den von der angehefteten Verknüpfung.
Danke und Grüße
Cody
Ich musste leider kürzlich von Windows 10 auf 11 umsteigen. Jetzt nervt mich ein merkwürdiges Verhalten. Wenn ich die Befehlszeile übers Startmenü mit CMD.EXE aufrufe und dann über das Kontextmenü des Taskbuttons an der Taskleiste anhefte, erscheint beim nächsten Klick darauf nicht CMD.EXE sondern PS.EXE - also die Power Shell. Die aber will und brauche ich nicht.
Ich habe mir dann erstmal damit geholfen, dass ich manuell eine Verknüpfung zu CMD.EXE auf dem Desktop erstellt und in die Taskleiste gezogen habe. Das aber ist nicht gleichbedeutend mit einem angehefteten Programm, denn wenn man darüber ein DOS-Fenster öffnet, hat man den Eintrag doppelt in der Taskleiste (einmal den vom aktiven Fenster und dann noch mal den von der angehefteten Verknüpfung.
Danke und Grüße
Cody
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673189
Url: https://administrator.de/forum/cmd-exe-windows-11-taskleiste-673189.html
Ausgedruckt am: 18.07.2025 um 01:07 Uhr
37 Kommentare
Neuester Kommentar
Doch du willst die Powershell nutzen. 
Oder du nimmst wie von Microsoft gewünscht das Terminal und definierst die CMD als Standartshell.
Und natürlich kannst du die an die Taskleiste anpinnen.
Oder du nimmst wie von Microsoft gewünscht das Terminal und definierst die CMD als Standartshell.
Und natürlich kannst du die an die Taskleiste anpinnen.
Wenn ich die Befehlszeile übers Startmenü mit CMD.EXE aufrufe und dann über das Kontextmenü des Taskbuttons an der Taskleiste anhefte, erscheint beim nächsten Klick darauf nicht CMD.EXE sondern PS.EXE
Einfach nur den Standard-Terminal auf den Console-Host zurück setzen, oder im Windows Terminal die CMD als Standard setzen, dann passiert das auch nicht ..
3
Bei mir kann man cmd an der Taskleiste anpinnen. Funktioniert.
Moment, da steht ja wirklich powershell drüber...
Egal, funktioniert. Ist wie ein DOS Fenster benutzbar, ist auch mit schwarzem Hintergrund. Passt, mehr brauch ich nicht.
Moment, da steht ja wirklich powershell drüber...
Egal, funktioniert. Ist wie ein DOS Fenster benutzbar, ist auch mit schwarzem Hintergrund. Passt, mehr brauch ich nicht.
1
Nennt sich Windows Terminal App und lässt sich in der Systemsteuerung auch wieder auf den alten Console Host umstellen wenn man keine App haben will wenn man CMD eintippselt 😁.
2
Warum sind so viele gegen die Powershell...
2Das hat doch damit überhaupt nichts zu tun, hier wird einfach nur die Frage des TOs beantwortet, nicht mehr nicht weniger.
2
Kommt drauf an.
Für die Powershell muss man ggf. Kommandos speziell aufbereiten. Escapen, etc. damit es literal übernommen wird.
cmd /c
-ArgumentList ....
Ohne dass ist das Verhalten ggf. unerwartet.
Powershell hat seinen Anwendungsbereich, wenn man den aber anders abdeckt, braucht man halt kein Powershell.
Ich für meinen Teil bin VBS Script Freak und finde das deutlich kompfortabler, und wenn ich Powershell Befehl nutzen will weils z.B. besser mit Eventlog Checks umgehen kann rufe ich aus VBS heraus Powershell per dynamische Codezeile die ich generieren lasse und speicher mit den result als txt file ab und lese das wiederum in VBS ein und arbeite dort weiter....
Weil mal ehrlich wenn man klassisch if else und do until oder for next, if like usw... nutzen will da geht mir powershell unendlich aufn kecks mit seinem syntax... und gespickt mit arrays usw... ebenfalls...
Daher ja ich mag Powershell nicht....
Und weil ich halt von früher komme, als Powershell noch seperat installiert werden musste damits geht...
war es halt damals als unnütz angesehen, wenn man direkt mit dem System poppeln will, und zwar native.
ABER da meinche Hersteller APIs gemacht haben, zu Powershell, kommt man inzwischen nicht drum rum, sei es im Server Installationsbereich oder Client Bereich, wenn man bestimmte sachen automatisieren will...
DOS Pur finde ich ebenfalls doof aber DOS hat halt manch mächtige Befehle die man wiederum auch aus VBS ausführen kann...
Und da VBS Script ebenfalls LDAP, SQL, MySQL, DBASE oder sonstige Datenbanken auch direkt anzapfen kann empfinde ich es halt als allround tool am besten
Aber jeder kann ja tun und lassen was er will
DOS benutze ich vor allem zu diagnosezwecken...
Powershell nur bedingt... 1-2 Befehle oder so...
Ich für meinen Teil bin VBS Script Freak und finde das deutlich kompfortabler, und wenn ich Powershell Befehl nutzen will weils z.B. besser mit Eventlog Checks umgehen kann rufe ich aus VBS heraus Powershell per dynamische Codezeile die ich generieren lasse und speicher mit den result als txt file ab und lese das wiederum in VBS ein und arbeite dort weiter....
Weil mal ehrlich wenn man klassisch if else und do until oder for next, if like usw... nutzen will da geht mir powershell unendlich aufn kecks mit seinem syntax... und gespickt mit arrays usw... ebenfalls...
Daher ja ich mag Powershell nicht....
Und weil ich halt von früher komme, als Powershell noch seperat installiert werden musste damits geht...
war es halt damals als unnütz angesehen, wenn man direkt mit dem System poppeln will, und zwar native.
ABER da meinche Hersteller APIs gemacht haben, zu Powershell, kommt man inzwischen nicht drum rum, sei es im Server Installationsbereich oder Client Bereich, wenn man bestimmte sachen automatisieren will...
DOS Pur finde ich ebenfalls doof aber DOS hat halt manch mächtige Befehle die man wiederum auch aus VBS ausführen kann...
Und da VBS Script ebenfalls LDAP, SQL, MySQL, DBASE oder sonstige Datenbanken auch direkt anzapfen kann empfinde ich es halt als allround tool am besten
Aber jeder kann ja tun und lassen was er will
DOS benutze ich vor allem zu diagnosezwecken...
Powershell nur bedingt... 1-2 Befehle oder so...
@Crusher79
Da hast du Recht, wollte aber nicht darauf hinaus.
Klar ist die CMD bei bestimmten Dingen "schneller", aber wenn es richtung .Bat vs .ps1 geht ist PS eleganter.
Z.B die Funktionalität von nslookup vs Resolve-DnsName. Resolve-DnsName bildet mehr die Namensauflösung des OS nach, nslookup fragt stumpf den DNS. Wenn der Rechner noch IPv6 hat dann hat nslookup 0 Aussagekraft um die IP zur Kommunikation zu finden.
Warum also nicht langsam an die PS Syntax gewöhnen bzw. neue Scraipts statt in BAT in ps1 schreiben.
Da hast du Recht, wollte aber nicht darauf hinaus.
Klar ist die CMD bei bestimmten Dingen "schneller", aber wenn es richtung .Bat vs .ps1 geht ist PS eleganter.
Z.B die Funktionalität von nslookup vs Resolve-DnsName. Resolve-DnsName bildet mehr die Namensauflösung des OS nach, nslookup fragt stumpf den DNS. Wenn der Rechner noch IPv6 hat dann hat nslookup 0 Aussagekraft um die IP zur Kommunikation zu finden.
Warum also nicht langsam an die PS Syntax gewöhnen bzw. neue Scraipts statt in BAT in ps1 schreiben.
Bei mir ist es genau so wie, vom TO gewünscht. Ohne, dass ich irgendetwas umgestellt hätte
Ab dem zweiten Tab wird allerdings die Powershell geöffnet. Was das soll weiß man vermutlich nur in Redmond.
Ab dem zweiten Tab wird allerdings die Powershell geöffnet. Was das soll weiß man vermutlich nur in Redmond.
Zitat von @manuel-r:
Ab dem zweiten Tab wird allerdings die Powershell geöffnet. Was das soll weiß man vermutlich nur in Redmond.
Ab dem zweiten Tab wird allerdings die Powershell geöffnet. Was das soll weiß man vermutlich nur in Redmond.
Kerl, stell doch in den Einstellungen mal Standardprofil auf Eingabeauffordung um.
Und nun macht + DOS! ... Naja, das was man so als 98er hängengebliebener sagen würde.
Zitat von @Delta9:
@Crusher79
Da hast du Recht, wollte aber nicht darauf hinaus.
Klar ist die CMD bei bestimmten Dingen "schneller", aber wenn es richtung .Bat vs .ps1 geht ist PS eleganter.
@Crusher79
Da hast du Recht, wollte aber nicht darauf hinaus.
Klar ist die CMD bei bestimmten Dingen "schneller", aber wenn es richtung .Bat vs .ps1 geht ist PS eleganter.
Klar. Ich nutze zu 99% PS. Ebenfalls auch in Verbindung mit PSEnter-Session.
Normale "cmd" commands liefern dort ja auch eine $LASTEXITCODE und lassen sich dann gut in if-Blocks zwängen.
Ich begehe sogar einen Frevel. Nutze PS unter Debian um Dinge umzusetzen. Geht ganz gut.
Zitat von @BiberMan:
Wenn ich die Befehlszeile übers Startmenü mit CMD.EXE aufrufe und dann über das Kontextmenü des Taskbuttons an der Taskleiste anhefte, erscheint beim nächsten Klick darauf nicht CMD.EXE sondern PS.EXE
Einfach nur den Standard-Terminal auf den Console-Host zurück setzen, oder im Windows Terminal die CMD als Standard setzen, dann passiert das auch nicht ..Standardprofil würde reichen. Eine Zeile höher. Aber im Prinzip genauso in der Art.
Und nun macht + DOS! ... Naja, das was man so als 98er hängengebliebener sagen würde.
Fallweise nutze ich mal die alte Kommandozeile und mal die Powershell.
Mich stört es auch nicht, weil ich die Tabs an der Stelle eh nicht mag, starte ich die Kommandozeile wenn ich sie brauche einfach mehrfach. Es wundert mich einfach, dass ab dem zweiten Tab die Powershell gestartet wird.
Manuel
Zitat von @manuel-r:
Es wundert mich einfach, dass ab dem zweiten Tab die Powershell gestartet wird.
Manuel
Es wundert mich einfach, dass ab dem zweiten Tab die Powershell gestartet wird.
Manuel
Dann ja nicht mehr.
Default ist es immer PS. Denke cmd.exe als input parameter triggert das neue terminal command prompt to starten.
Ohne start parameter kommt PS.
Es sei denn man stellt das wie oben dargestellt um.
Wer cmd.exe called will ja auch genau diese haben. Ggf sieht man es in systinternals process monitor, was da übergeben wird.
Aber das dürfte der Grund sein.
Cmd.exe nicht nur Programm, sondern auch input Parameter für das terminal Programm. Macht ja auch Sinn
Tabs ist ja nur die halbe Wahrheit. Es sind ganze Profile dahinter. Du kannst auch neue Profile erstellen. Auch eines, was direkt als Administrator startet. Oder PowerShell 7 statt PowerShell 5.x
Ansonsten fehlt was. Dafür gibt halt ISE oder Visual Studio Code - auch gleich zum debuggen.
Also vom Ansatz her nicht schlecht.
Im Prinzip ähnlich wie beim Norton Commander - nur halt für Befehle.... Tabs und Split Screen sind schon ein Brett. Je nach Anwendungsfall auch ein game changer.
Moin @NordicMike,
ähm, Vorsicht!
Zwar lassen sich über die PS-Console auch CMD Befehle oder auch EXE's ausführen, mann sieht darüber dann aber nicht immer die vollständigen Rückinfos/Statusinfos des entsprechenden CMD Befehls oder der EXE. 😔
Gruss Alex
Egal, funktioniert. Ist wie ein DOS Fenster benutzbar, ist auch mit schwarzem Hintergrund. Passt, mehr brauch ich nicht.
ähm, Vorsicht!
Zwar lassen sich über die PS-Console auch CMD Befehle oder auch EXE's ausführen, mann sieht darüber dann aber nicht immer die vollständigen Rückinfos/Statusinfos des entsprechenden CMD Befehls oder der EXE. 😔
Gruss Alex
Zitat von @MysticFoxDE:
Moin @NordicMike,
ähm, Vorsicht!
Moin @NordicMike,
Egal, funktioniert. Ist wie ein DOS Fenster benutzbar, ist auch mit schwarzem Hintergrund. Passt, mehr brauch ich nicht.
ähm, Vorsicht!
Bzw bei Servern noch schlimmer. X86 oder x64?
Da erlebt man auch eine Überraschung, selbst wenn es weiß auf schwarz dort steht.
Wäre zwar nur PS in dem Fall, aber mit nervigen Fehlern... Selbst wenn es ähnlich aussieht.
1
Weil ich lieber die bash benutze.
Zur Not geht auch tcsh oder ksh.
lks
Zitat von @BiberMan:
Nennt sich Windows Terminal App und lässt sich in der Systemsteuerung auch wieder auf den alten Console Host umstellen wenn man keine App haben will wenn man CMD eintippselt 😁.
Nennt sich Windows Terminal App und lässt sich in der Systemsteuerung auch wieder auf den alten Console Host umstellen wenn man keine App haben will wenn man CMD eintippselt 😁.
App oder Konsole hätte mich nicht weiter gestört und Tabbed-UI kann auch mal ganz praktisch sein. Mir ging es vorallem darum, dass die App bei einem direkten Aufruf immer in die Power Shell gestartet ist.
Zitat von @manuel-r:
Bei mir ist es genau so wie, vom TO gewünscht. Ohne, dass ich irgendetwas umgestellt hätte
Ab dem zweiten Tab wird allerdings die Powershell geöffnet. Was das soll weiß man vermutlich nur in Redmond.
Bei mir ist es genau so wie, vom TO gewünscht. Ohne, dass ich irgendetwas umgestellt hätte
Ab dem zweiten Tab wird allerdings die Powershell geöffnet. Was das soll weiß man vermutlich nur in Redmond.
Genau das. Solcherlei "Zwangsbeglückung" löst bei mir Abwehrreaktionen aus. Wenn ich die PS brauche, starte ich die auch. In aller Regel brauche aber CMD. Die beiden sind nicht gleichbedeutend und PS ist kein Superset von CMD. Ein Beispiel: Für eine schnelle Dateisuche nutze ich gerne CMD:
cd \
dir Irgendeine.txt /b /s
CMD findet die Datei(en) um ein Vielfaches schneller als eine Suche über den Windows-Explorer. Und die Power Shell sagt dazu nur: "Get-ChildItem : Es wurde kein Positionsparameter gefunden, der das Argument "/s" akzeptiert."
Wie gesagt es ist nur ein Beispiel. Womöglich kann die PS auch Dateien suchen. Befehlskompatibel ist sie jedenfalls nicht.
Zitat von @Codehunter:
CMD findet die Datei(en) um ein Vielfaches schneller als eine Suche über den Windows-Explorer. Und die Power Shell sagt dazu nur: "Get-ChildItem : Es wurde kein Positionsparameter gefunden, der das Argument "/s" akzeptiert."
CMD findet die Datei(en) um ein Vielfaches schneller als eine Suche über den Windows-Explorer. Und die Power Shell sagt dazu nur: "Get-ChildItem : Es wurde kein Positionsparameter gefunden, der das Argument "/s" akzeptiert."
Das ist ein ganz schlechter Vergleich!
cmd /c "dir Irgendeine.txt /b /s"
Moin @Crusher79,
ähm ... ja ... da war doch erst jüngst hier etwas ...
Windows Server 2025 - mal mit mal ohne Remove-WindowsFeature
... in der Richtung. 🙃
Ist übrigens nicht nur bei den Servern sondern auch bei W11 so. 😔
Gruss Alex
Bzw bei Servern noch schlimmer. X86 oder x64?
Da erlebt man auch eine Überraschung, selbst wenn es weiß auf schwarz dort steht.
Wäre zwar nur PS in dem Fall, aber mit nervigen Fehlern... Selbst wenn es ähnlich aussieht.
Da erlebt man auch eine Überraschung, selbst wenn es weiß auf schwarz dort steht.
Wäre zwar nur PS in dem Fall, aber mit nervigen Fehlern... Selbst wenn es ähnlich aussieht.
ähm ... ja ... da war doch erst jüngst hier etwas ...
Windows Server 2025 - mal mit mal ohne Remove-WindowsFeature
... in der Richtung. 🙃
Ist übrigens nicht nur bei den Servern sondern auch bei W11 so. 😔
Gruss Alex
Zitat von @Crusher79:
Das ist ein ganz schlechter Vergleich!
Zitat von @Codehunter:
CMD findet die Datei(en) um ein Vielfaches schneller als eine Suche über den Windows-Explorer. Und die Power Shell sagt dazu nur: "Get-ChildItem : Es wurde kein Positionsparameter gefunden, der das Argument "/s" akzeptiert."
CMD findet die Datei(en) um ein Vielfaches schneller als eine Suche über den Windows-Explorer. Und die Power Shell sagt dazu nur: "Get-ChildItem : Es wurde kein Positionsparameter gefunden, der das Argument "/s" akzeptiert."
Das ist ein ganz schlechter Vergleich!
cmd /c "dir Irgendeine.txt /b /s" Warum umständlich, wenn es auch einfacher geht?
Jedesmal ein cmd /c vornwegzutippen ist nerviger als direkt die cmd-shell zu benutzen.
Es ist ganz einfach: jeder hat seine lieblingsshell. Und man kann für jede Aufgabe die dafür geeignete Shell nutzen.ich benutze unter Windows, je nach Aufgabenstellung cmd, PS und bash, wobei meine bevorzugte Shell unter Windows cmd ist.
lks
Zitat von @Lochkartenstanzer:
Warum umständlich, wenn es auch einfacher geht?
Jedesmal ein cmd /c vornwegzutippen ist nerviger als direkt die cmd-shell zu benutzen.
Warum umständlich, wenn es auch einfacher geht?
Jedesmal ein cmd /c vornwegzutippen ist nerviger als direkt die cmd-shell zu benutzen.
Tu ich ja auch nicht.
@Codehunter hat den Fehler eingeworfen. Den jeder der PS und Eingabeaufforderung kennt schon mal gesehen hat.
Das wäre nur eine Lösung. Ggf. auch für native alte Programme, die man in PS integrieren will. Mal abgesehen von Start-Process, parallel Verarbeitung und den ganzen PS Sauereien
Wie gesagt, die Profile bieten mehr als ein schnöder Aufruf. Ändert man Standardprofil merkt man kaum einen Unterschied.
Ich PowerShell
Ka Array? Irgemndwas fehlte mir bei den beiden. RAID Controller überwache ich mit Bash. Auch wöchentliche Test-Email.Bei anderen finde ich Get-ChildItem auch unter Debian schneller. Außer die Pfade ist der Syntax ja fast zu 99% identisch bei PS. Bin mit PowerShell 7.x unter Debian zufriedener als mit den beiden Bash-Lösungen.
Moin @Delta9,
na ja, so viele sind es nun auch nicht und die die es noch nicht mögen, kennen lediglich dessen Power noch nicht wirklich. 🙃
Gruss Alex
Warum sind so viele gegen die Powershell...
na ja, so viele sind es nun auch nicht und die die es noch nicht mögen, kennen lediglich dessen Power noch nicht wirklich. 🙃
Gruss Alex
Vor allem wenn man die falschen Parameter benutzt /s ist bei gci -recursive. Also im Verzeichnis gci irgendeinedatei.txt -recursive
Durch autovervollständigen (tab) sindbes auch nicht wirklich mehr tastenschläge.
Durch autovervollständigen (tab) sindbes auch nicht wirklich mehr tastenschläge.
Zitat von @Delta9:
Vor allem wenn man die falschen Parameter benutzt /s ist bei gci -recursive. Also im Verzeichnis gci irgendeinedatei.txt -recursive
Vor allem wenn man die falschen Parameter benutzt /s ist bei gci -recursive. Also im Verzeichnis gci irgendeinedatei.txt -recursive
Tut er ja nicht! Mehr oder minder absichtlich zumindest.... Man muss schon schauen wo man hinklickt. Schrift auf schwarzen Grund = DOS/ Eingabeaufforderung. Auch die PS kann man statt blau schwarz färben.
Windows hat sich halt weiterentwickelt. Friss oder Stirb - ist leider so. Man muss etwas aufgeschlossen gegenübertreten. Sonst bleibt man immerm wieder hängen.
Zitat von @ThePinky777:
Ich für meinen Teil bin VBS Script Freak und finde das deutlich kompfortabler, und wenn ich Powershell Befehl nutzen will weils z.B. besser mit Eventlog Checks umgehen kann rufe ich aus VBS heraus Powershell per dynamische Codezeile die ich generieren lasse und speicher mit den result als txt file ab und lese das wiederum in VBS ein und arbeite dort weiter....
Ich für meinen Teil bin VBS Script Freak und finde das deutlich kompfortabler, und wenn ich Powershell Befehl nutzen will weils z.B. besser mit Eventlog Checks umgehen kann rufe ich aus VBS heraus Powershell per dynamische Codezeile die ich generieren lasse und speicher mit den result als txt file ab und lese das wiederum in VBS ein und arbeite dort weiter....
Von VBS sollte man dann aber vielleicht doch mal umsteigen.
techcommunity.microsoft.com/blog/windows-itpro-blog/vbscript-dep ...
Zitat von @MysticFoxDE:
na ja, so viele sind es nun auch nicht und die die es noch nicht mögen, kennen lediglich dessen Power noch nicht wirklich. 🙃
na ja, so viele sind es nun auch nicht und die die es noch nicht mögen, kennen lediglich dessen Power noch nicht wirklich. 🙃
Mehrere TB an Dateien kopieren. PowerShell 7 und parallel Task - > 2 - 5 GBit/s wenn man z.B. rsync damit aufruft. Ginge auch so, aber ich habs mal damit kombiniert.
Wie soll man sonst 10 GBit/s ausreizen? Gut, man kann auch cmd mehrfach starten etc. Hier ist es bei den Script Blöcken ein Wort mehr "-parallel" und die Magie beginnt.
Moin @Delta9,
oder diese neumodischen "KI" (KEINE INTELLIGENZ) zum generieren der Skripte benutzt, denn das was die mittlerweile ausspucken, kann man vor allem meinen jüngsten Erfahrungen nach, noch nicht mal den 🐰🐰 zum Fressen geben. 😔
Gruss Alex
Vor allem wenn man die falschen Parameter benutzt
oder diese neumodischen "KI" (KEINE INTELLIGENZ) zum generieren der Skripte benutzt, denn das was die mittlerweile ausspucken, kann man vor allem meinen jüngsten Erfahrungen nach, noch nicht mal den 🐰🐰 zum Fressen geben. 😔
Gruss Alex
Vor allem die generelle Interaktion mit Sachen wie Zertifikatsspeicher oder registry oder oder sind einfacher.
Oder ne yaml, yml mal in ne csv oder umgekehrt wandeln.
Oder ne yaml, yml mal in ne csv oder umgekehrt wandeln.
Moin @Crusher79,
wenn die NIC's und auch der TCP-Stack, per Default korrekt konfiguriert währen, dann währe das theoretisch auch kein grosses Problem, vor allem bei Windows.
Denn wenn dieses korrekt eingestellt ist, was jedoch nicht ganz einfach ist, da viele Einstellungen von der verwendeten Hardware abhängen, dann ist eine Auslastung von 10G vor allem mit dem kopieren von grossen Dateien per SMB, überhaupt kein Problem, da der SMB-Stack selbst bereits parallelisiert, aber nur dann, wenn RSS ordentlich konfiguriert und auch funktionsfähig ist.
Und auch selbst ohne RSS ist es bei einem ordentlich konfiguriertem System, ohne Probleme möglich, bereits mit einer TCP-Window-Size von gerade mal 16K, einen 10G Link bis zum Anschlag auszulasten, zumindest bei einer Kurzstrecke.
By the way, wenn du unter Windows Dateien schnell von A nach B über das Netzwerk (SMB) kopieren möchtest, dann funktioniert das mitunter auch gut mit den Boardmitteln, sprich mit xcopy oder robocopy, aber nur dann, wenn man auch den "/J" Parameter mitverwendet. 😉
Robocopy macht übrigens per Default Multithreadkopien, was aber nur bedeutet, dass es bis zu 8 Dateien gleichzeitig kopieren kann, was beim Kopieren von grossen Dateien jedoch nicht viel bring, bei kleinen hingegen schon. Siehe auch "/MT" Parameter, mit dem man die Anzahl der oben angesprochenen Multithreadkopien auch noch etwas "feiner" steuern kann.
Gruss Alex
Wie soll man sonst 10 GBit/s ausreizen?
wenn die NIC's und auch der TCP-Stack, per Default korrekt konfiguriert währen, dann währe das theoretisch auch kein grosses Problem, vor allem bei Windows.
Denn wenn dieses korrekt eingestellt ist, was jedoch nicht ganz einfach ist, da viele Einstellungen von der verwendeten Hardware abhängen, dann ist eine Auslastung von 10G vor allem mit dem kopieren von grossen Dateien per SMB, überhaupt kein Problem, da der SMB-Stack selbst bereits parallelisiert, aber nur dann, wenn RSS ordentlich konfiguriert und auch funktionsfähig ist.
Und auch selbst ohne RSS ist es bei einem ordentlich konfiguriertem System, ohne Probleme möglich, bereits mit einer TCP-Window-Size von gerade mal 16K, einen 10G Link bis zum Anschlag auszulasten, zumindest bei einer Kurzstrecke.
By the way, wenn du unter Windows Dateien schnell von A nach B über das Netzwerk (SMB) kopieren möchtest, dann funktioniert das mitunter auch gut mit den Boardmitteln, sprich mit xcopy oder robocopy, aber nur dann, wenn man auch den "/J" Parameter mitverwendet. 😉
Robocopy macht übrigens per Default Multithreadkopien, was aber nur bedeutet, dass es bis zu 8 Dateien gleichzeitig kopieren kann, was beim Kopieren von grossen Dateien jedoch nicht viel bring, bei kleinen hingegen schon. Siehe auch "/MT" Parameter, mit dem man die Anzahl der oben angesprochenen Multithreadkopien auch noch etwas "feiner" steuern kann.
Gruss Alex
1Zitat von @MysticFoxDE:
wenn die NIC's und auch der TCP-Stack, per Default korrekt konfiguriert währen, dann währe das theoretisch auch kein grosses Problem, vor allem bei Windows.
[...], was jedoch nicht ganz einfach ist, da viele Einstellungen von der verwendeten Hardware abhängen, [...]
Kannst du diesen Widerspruch mal für mich auflösen? Wie soll etwas per default korrekt konfiguriert sein wenn es wegen Hardwareabhängigkeiten gar keinen Default gibt?
/Thomas
Moin @Th0mKa,
du hast mich missverstanden oder ich mich missverständlich ausgedrückt. 🙃
Nehmen wir gerade mal RSS (Receive Side Scaling) als Beispiel ...
learn.microsoft.com/en-us/windows-hardware/drivers/network/intro ...
... was in Verbindung mit dem Thema Netzwerkperformance, eines der wichtigsten Features ist, zumindest dann, wenn es auch optimal konfiguriert ist. Denn ohne RSS, wird die gesamte Last der entsprechenden Netzwerkkarte, nur über einen Kern abgewickelt und zwar den aller ersten, zumindest ist das bei Windows so und bei Linux ist das meines Wissens nach auch nicht anders, ausser, dass dort dieses Feature etwas anders heisst. Auf jeden Fall kannst du mit nur einem Kern nur eine bestimmte Last abtragen und die liegt je nach CPU-Takt, normalerweise so bei ~ 3-4 GBit/s, bei hoch getakteten Kernen können es aber auch 5-6 GBit/s sein.
Somit ist für eine Auslastung einer 1G NIC , bereits schon 1 Kern eigentlich volkommen ausreichend und bei 10G, sind mehr als 4 in den meisten fällen auch nicht notwendig und auch nicht wirklich besser. Denn mit jedem weiteren Kern/Queue, die von einem NIC-Port für die Verarbeitung des Datenverkehrs verwendet werden, fällt auch ein höherer Verwaltungsaufwand an der neben etwas RAM, vor allem auch CPU-Leistung frisst ohne dafür jedoch auch einen Mehrwert/Nutzen zu erziehlen.
Bei 1G sollte RSS eigentlich auf max. 2 Kernen/Queues laufen, bei 10G wie schon angesprochen mit max. 4 Kernen/Queues und bei 25G mit max. 8 Kernen/Queues, denn alles andere ist eine reine Ressourcenverschwendung und auch Handbremse. Diese Aussage gilt übrigens für die Reale Uplinkgeschwindigkeit des jeweiligen NIC Ports und nicht für die, die er maximal könnte. Sprich, wenn eine 25G NIC warum auch immer nur mit 1G läuft, dann benötigt diese für das Händling des entsprechenden Datenverkehrs, auch nur 2 Kernen/Queues.
Die Default/Vorgaben von Microsoft sehen aber folgend aus ...
Quelle:
learn.microsoft.com/en-us/windows-hardware/drivers/network/stand ...
... sprich 16 Kerne/Queues und zwar ganz unabhängig davon, was die entsprechende NIC max. kann oder mit was sie gerade tatsächlich läuft.
Dabei wäre es für MS eigentlich überhaupt kein Problem, die Konfiguration von RSS in abhänghigkeit der reallen Uplinkgeschwindigkeit korrekt zu konfigurieren, was die jedoch seit über 20 Jahren nicht wirklich auf die Reihe bekommen. 😭
Und spättestens sobald Virtualisierung im Spiel ist, wird das Thema noch um einiges komplizierter, da hier noch vRSS, VM(M)Q oder SR-IOV ins Spiel kommen, die per Default auch nicht besser konfiguriert sind und zwar nicht nur bei Microsoft. 😔
Gruss Alex
Wie soll etwas per default korrekt konfiguriert sein wenn es wegen Hardwareabhängigkeiten gar keinen Default gibt?
du hast mich missverstanden oder ich mich missverständlich ausgedrückt. 🙃
Nehmen wir gerade mal RSS (Receive Side Scaling) als Beispiel ...
learn.microsoft.com/en-us/windows-hardware/drivers/network/intro ...
... was in Verbindung mit dem Thema Netzwerkperformance, eines der wichtigsten Features ist, zumindest dann, wenn es auch optimal konfiguriert ist. Denn ohne RSS, wird die gesamte Last der entsprechenden Netzwerkkarte, nur über einen Kern abgewickelt und zwar den aller ersten, zumindest ist das bei Windows so und bei Linux ist das meines Wissens nach auch nicht anders, ausser, dass dort dieses Feature etwas anders heisst. Auf jeden Fall kannst du mit nur einem Kern nur eine bestimmte Last abtragen und die liegt je nach CPU-Takt, normalerweise so bei ~ 3-4 GBit/s, bei hoch getakteten Kernen können es aber auch 5-6 GBit/s sein.
Somit ist für eine Auslastung einer 1G NIC , bereits schon 1 Kern eigentlich volkommen ausreichend und bei 10G, sind mehr als 4 in den meisten fällen auch nicht notwendig und auch nicht wirklich besser. Denn mit jedem weiteren Kern/Queue, die von einem NIC-Port für die Verarbeitung des Datenverkehrs verwendet werden, fällt auch ein höherer Verwaltungsaufwand an der neben etwas RAM, vor allem auch CPU-Leistung frisst ohne dafür jedoch auch einen Mehrwert/Nutzen zu erziehlen.
Bei 1G sollte RSS eigentlich auf max. 2 Kernen/Queues laufen, bei 10G wie schon angesprochen mit max. 4 Kernen/Queues und bei 25G mit max. 8 Kernen/Queues, denn alles andere ist eine reine Ressourcenverschwendung und auch Handbremse. Diese Aussage gilt übrigens für die Reale Uplinkgeschwindigkeit des jeweiligen NIC Ports und nicht für die, die er maximal könnte. Sprich, wenn eine 25G NIC warum auch immer nur mit 1G läuft, dann benötigt diese für das Händling des entsprechenden Datenverkehrs, auch nur 2 Kernen/Queues.
Die Default/Vorgaben von Microsoft sehen aber folgend aus ...
Quelle:
learn.microsoft.com/en-us/windows-hardware/drivers/network/stand ...
... sprich 16 Kerne/Queues und zwar ganz unabhängig davon, was die entsprechende NIC max. kann oder mit was sie gerade tatsächlich läuft.
Dabei wäre es für MS eigentlich überhaupt kein Problem, die Konfiguration von RSS in abhänghigkeit der reallen Uplinkgeschwindigkeit korrekt zu konfigurieren, was die jedoch seit über 20 Jahren nicht wirklich auf die Reihe bekommen. 😭
Und spättestens sobald Virtualisierung im Spiel ist, wird das Thema noch um einiges komplizierter, da hier noch vRSS, VM(M)Q oder SR-IOV ins Spiel kommen, die per Default auch nicht besser konfiguriert sind und zwar nicht nur bei Microsoft. 😔
Gruss Alex
Das ist leider ein bekanntes Verhalten unter Windows 11. Microsoft leitet den cmd.exe-Start oft auf PowerShell oder Windows Terminal um.
Dein Workaround mit der Verknüpfung ist schon fast die beste Lösung.
Alternativ kannst du im Windows Terminal "Einstellungen" → "Startprogramm" → "cmd.exe" als Standard festlegen.
Oder du nutzt eine direkt erstellte Verknüpfung mit Ziel C:\Windows\System32\cmd.exe und ziehst diese in die Taskleiste — damit bleibt es wirklich cmd.exe.
Ganz umgehen lässt sich das doppelte Symbol momentan leider nicht elegant.
Dein Workaround mit der Verknüpfung ist schon fast die beste Lösung.
Alternativ kannst du im Windows Terminal "Einstellungen" → "Startprogramm" → "cmd.exe" als Standard festlegen.
Oder du nutzt eine direkt erstellte Verknüpfung mit Ziel C:\Windows\System32\cmd.exe und ziehst diese in die Taskleiste — damit bleibt es wirklich cmd.exe.
Ganz umgehen lässt sich das doppelte Symbol momentan leider nicht elegant.
Für die eigene Arbeit kein Problem. Für die Bereitstellung an andere, insbesondere Laien, sind oft zu viele Voraussetzungen zu definieren. Gerne auch Dinge, die dem Unbedarften zu viele Möglichkeiten eröffnen.
