maggreg

Jeszcze raz zapytam, boot menu nie działa? Jeżeli to Asus to może być F8, na laptopach najczęściej to jest f11, f12 również esc. Jeżeli w napędzie będzie płyta komputer powinien rozpoznać czy zawiera konfigurację efi i zaproponować do wyboru odpowiednią opcję startu. Oczywiście nośnik instalacyjny musi zawierać wersję 64bit systemu oraz odpowiednią konfigurację (katalog efi z plikami). Ja i tak wybrałbym dism z poziomu dziesiątki . Operacje przedstawione na tym filmiku nie są konieczne z punktu widzenia instalacji w trybie efi z drugiej strony secure boot tylko zmniejsza ilość opcji w imię (wątpliwego) podwyższenia bezpieczeństwa, csm warto włączyć ze względu na kompatybilność urządzeń (choć znów siódemka powinna obsłużyć sprzęt w natywnym efi), fastboot może przeszkadzać w złapaniu bootmenu (opóźniona inicjacja klawiatury). pzdr

Nie widzę twojego biosu ale mogę zgadnąć, że w kolejności botowania powinny być dwa oddzielne wpisy dla napędu optycznego poza tym po co przestawiać bios dla pojedynczego botowania, bootmenu nie działa? pzdr

Podane poprawki są w tej chwili obligatoryjne również po świeżej instalacji systemu inaczej taki windows nie potrafi "skorzystać" z windows update. pzdr

To jest problem "durnego" instalatora windows a nie systemu jako takiego, instalator potrafi zainstalować system tylko w trybie w jakim sam został odpalony, musisz zabotować płytę w trybie uefi. Alternatywnie można użyć metody "ręcznej" i postawić system z pomocą imagex/dism (czy też wimlib-imagex) + bcdboot - można to nawet zrobić z poziomu tej dziesiątki. pzdr

A dlaczego musisz? Jakiś problem z siódemką na GPT? pzdr

Czy instalowałeś zalecane w takim przypadku poprawki: KB3020369 i KB3172605 https://www.microsoft.com/pl-pl/download/details.aspx?id=46827 https://www.microsoft.com/en-us/download/details.aspx?id=53332 ? pzdr

Katalogi temp zarówno dla sytemu jak i obecnego użytkownika ustawia się w zmiennych systemowych (szukaj w zaawansowanych ustawieniach systemu). Katalogi te biorą udział w procesie instalacji poprawek ale nie przechowują samych pakietów, do tego służą katalogi "Installer" i "SoftwareDistribution". Teoretycznie można by je wyczyścić ale (zwłaszcza ten pierwszy) może sprawiać problemy przy późniejszych updatach czy deinstalacjach. Proponuję najpierw wyczyścić system stosownym narzędziem - cleanmgr (zwłaszcza pozostałości po windows update). pzdr

Pewnie się da, zależy od skomplikowania struktury i powtarzalności kodu. Tylko kto by miał to zrobić jeśli nie ty? Raczej nikogo innego taka zabawa nie zainteresuje. pzdr

Niewykluczone, że dane te są podawane z innej domeny niż strona lub mają bardziej zagłębioną strukturę. Ponieważ w źródle strony są one zlinkowane z pełnym adresem to przeglądarka nie ma problemu z ich "podaniem" nawet gdy główna strona jest wczytana lokalnie. Tak przy okazji taki sposób zapisu powoduje, że mimo pobrania strony na dysk to dane i tak się będą ładować z sieci, musiałbyś zrobić edycję wszystkich plików html odwołujących się do danych i zmienić odwołania bezwzględne na względne. Dodatkowo w plikach mogą się znajdować niedozwolone znaki (dla danego systemu plików) które wget automatycznie zamieni podczas zapisu. Przykład z twojej strony: columns.css?ver=4.6.1 > pytajnik będzie zamieniony na małpę (większość o ile nie wszystkie skrypty z tej strony mają taką postać). Próbowałeś zwiększyć rekurencję? pzdr

Zainstalowaną wersję i edycję można odczytać z klucza rejestru: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion Jeżeli sprawdzasz z poziomu innego systemu to trzeba podpiąć odpowiedni (software) plik rejestru z katalogu: C:\Windows\System32\config W konsoli działającego systemu można odpytać komendą reg:Nazwa produktu: REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ProductName edycja: REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v EditionID poziom servicepack: REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CSDVersion wersja i build: REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentVersion REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild Z tego klucza można też odczytać klucz produktu ale wymaga on odkodowania. pzdr

W temacie który podlinkowałem jest to opisane. Zanim włączysz reco trzeba ustawić ścieżkę do odpowiedniego obrazu wim (ew. skopiować go najpierw w dogodne miejsce). pzdr

Prawdopodobnie system nie posiada prawidłowo utworzonego/zainicjowanego środowiska recovery opartego o winpe. Poszukaj sobie informacji o komendzie reagentc.exe i stowarzyszonych z nią operacji. np.: https://www.sepago.com/blog/2012/07/25/windows-recovery-environment-re-explained pzdr

http://www.dobreprogramy.pl/Po-aktualizacji-Windowsa-mniej-wladzy-w-rekach-admina-bo-Microsoft-wie-lepiej,News,75113.html pzdr

Nigdy nie zauważyłem takiego pliku na siódemce czy systemach serwerowych których używam. edit Ok troszkę of top - najwyżej usuniesz. W swoim systemie nie widzę w ogóle usługi TrkWks (nie ma po niej śladu w rejestrze) dlatego nie kojarzyłem pliku, dodatkowo jeżeli jest on powiązany np. z przywracaniem systemu (a jest to jedna z pierwszych rzeczy jaką wyłączam po zainstalowaniu systemu) to mogłem też nie zauważyć pliku na innych systemach dlatego był dla mnie zaskoczeniem (zwłaszcza jego pojawienie się na penie). Dodam jeszcze, że nie przypominam sobie wyrzucenia tej usługi z systemu więc mogło to być na początku jego funkcjonowania (w sierpniu minie siedem lat od pierwotnej instalacji), nie widzę żeby miało to negatywny wpływ na system - linki, junki itp. działają bez problemu. pzdr

Jakiś czas temu pisałem o tym, że dziesiątka spamuje katalogi "System Volume Information" plikiem "tracking.log", okazuje się że odpowiedzialna za to jest usługa "Klient śledzenia linków rozproszonych" czyli TrkWks. Teraz pojawił się nowy plik "WPSettings.dat" - tym razem odpowiada za niego "Usługa magazynu" czyli StorSvc. Użytkownicy zgłaszają, że ten mechanizm mocno męczy urządzenia magazynowe podłączane pod usb czasami blokując możliwość bezpiecznego wysunięcia. Ciekawe ile jeszcze śmieci MS będzie rozrzucał po dyskach (przypominam, że te pliki pojawiają się na wszystkich partycjach a nie tylko tej z systemem W10)? pzdr

Jeżeli myślisz o "żywym" systemie to nie jest to potrzebne natomiast w przypadku instalacji świeżo postawionego systemu powinno to skrócić czas aktualizacji (oczywiście najlepiej to zintegrować z instalką). Niestety paczka mimo, że MS deklaruje jej aktualność na kwiecień nie jest kompletna i tak czy siak system zassie coś ok. 90 poprawek - mimo wszystko dla osób wdrażających systemy jest to spore przyspieszenie procesu odświeżania obrazów wim - oszczędzimy też trochę miejsca, obraz wim aktualizowany tą poprawką (i dociągnietą resztą) jest ok 200MB mniejszy (po oczyszczeniu) niż aktualizowany od poziomu sp1 co może być pomocne w przypadku składaków typu AIO. Jeżeli miałbym spekulować czemu MS się na to zdecydował to obstawiłbym chęć odciążenia serwerów aktualizacyjnych, czytając narzekania użytkowników na proces aktualizacji win7 można dojść do wniosku, że MS przerzucił bazy tego systemu na starszą infrastrukturę zostawiając nowszą dla dziesiątki co spowodowało wyraźne wydłużenie procesu wyszukiwania poprawek dla siódemki - w zamyśle taka poprawka (po zintegrowaniu) powinna odciążyć serwery. pzdr

Już to kiedyś podawałem - skrypt wywalający gwx bez ruszania windowsupdate: @echo off @taskkill /f /im gwx.exe 2>nul >nul @takeown /f C:\Windows\System32\Tasks\Microsoft\Windows\Setup /r /d T 2>nul >nul @takeown /f C:\Windows\System32\Tasks\Microsoft\Windows\Setup /r /d Y 2>nul >nul @icacls C:\Windows\System32\Tasks\Microsoft\Windows\Setup /grant %username%:F /t 2>nul >nul @rd /s /q C:\Windows\System32\Tasks\Microsoft\Windows\Setup 2>nul @takeown /f C:\Windows\System32\GWX /r /d T 2>nul >nul @takeown /f C:\Windows\System32\GWX /r /d Y 2>nul >nul @icacls C:\Windows\System32\GWX /grant %username%:F /t 2>nul >nul @rd /s /q C:\Windows\System32\GWX 2>nul @if /i [%PROCESSOR_ARCHITECTURE%]==[AMD64] ( @takeown /f C:\Windows\SysWOW64\GWX /r /a /d T 2>nul >nul @takeown /f C:\Windows\SysWOW64\GWX /r /a /d Y 2>nul >nul @icacls C:\Windows\SysWOW64\GWX /grant %username%:F /t 2>nul >nul @rd /s /q C:\Windows\SysWOW64\GWX 2>nul ) @reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\GWX /f 2>nul >nul @reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\GWX /f 2>nul >nul @pause Zapisać jako cmd, odpalać jako administrator. pzdr

Czy koledzy orientują się który mechanizm tworzy w win10 plik tracking.log (plik znajduje się w System Volume Information). Plik zostaje umieszczony na wszystkich partycjach NTFS (nawet tych nie przypisanych w systemie), u mnie ma on 20kb, widzę tylko że przypisany jest do hosta usług (svhost) w kontekście usług sieciowych. Plik po skasowaniu tworzy się ponownie po ok 20s. pzdr

Ostatnio skrobnąłem sobie mały skrypt wywalający to całe GWX więc się podzielę, powinien działać tak samo w siódemce i ósemce (oczywiście odpalać jako admin), skrypt nie wywala samego biuletynu bezpieczeństwa który to wprowadzała więc nie powinien się odtwarzać (nie trzeba go ukrywać): @echo off @taskkill /f /im gwx.exe 2>nul @takeown /f C:\Windows\System32\Tasks\Microsoft\Windows\Setup /r /d T 2>nul @icacls C:\Windows\System32\Tasks\Microsoft\Windows\Setup /grant %username%:F /t >nul @rd /s /q C:\Windows\System32\Tasks\Microsoft\Windows\Setup 2>nul @takeown /f C:\Windows\System32\GWX /r /d T 2>nul @icacls C:\Windows\System32\GWX /grant %username%:F /t >nul @rd /s /q C:\Windows\System32\GWX 2>nul @if /i [%PROCESSOR_ARCHITECTURE%]==[AMD64] ( @takeown /f C:\Windows\SysWOW64\GWX /r /a /d T 2>nul @icacls C:\Windows\SysWOW64\GWX /grant %username%:F /t >nul @rd /s /q C:\Windows\SysWOW64\GWX 2>nul ) @reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\GWX /f 2>nul pzdr

Czyli zakładam, że sterownik ASIO? W takim razie z własnej praktyki mogę zaproponować ustawić średni bufor i długi czas (nawet najdłuższy jaki sterowniki pozwala ustawić, jeżeli nie wracasz sygnałem to nie ma dużego znaczenia). Przerabiałem podobny problem z presonusem pod firewire, był bardzo wybredny co do interfejsu, na kilku laptopach i np. na stacjonarnym kompie podłączony pod firewire w dźwiękówce creativa. Zadziałał bez "zacięć" dopiero na firewire wbudowanym w płytę (akurat zbiegło się u tego człeka z wymianą kompa więc to był jeden z priorytetów) natomiast na laptopie sprawę załatwił firewire na interfejsie pcimcia. To oczywiście sprawa chipsetu odpowiedzialnego za komunikację, oczywiście można się zastanawiać czy to problem sprzętu czy tylko sterownika choć pamiętam, że próba z macos też wypadała nieciekawie (oczywiście trzeba wziąć poprawkę, że był to "hackintosh"). Zakładając, że urządzenie podłączasz pod USB proponuję sprawdzić na różnych portach (sprawdzić w programie typu usbtreeview jakie urządzenia dzielą poszczególny kanał), sprawdzić inne wersje sterownika, spróbować inny kabel - nie koniecznie jakiś dedykowany audio "Wireworld" ale przede wszystkim długość (właściwie krótkość) kabla, jeżeli się da to wyłączyć zintegrowaną dźwiękówkę w bios i odinstalować sterowniki i dodatkowe oprogramowanie od niej. pzdr

Troszkę ogólne to pytanie. Co konkretnie chcesz osiągnąć? Przede wszystkim grub musi mieć wczytany sterownik usb i odpowiedni system plików (mogą być wkompilowane w samym grub): insmod usbms insmod ehci insmod uhci insmod ohci insmod part_msdos Jeżeli powyższe jest spełnione to usb powinno się pojawić jako kolejny napęd/dysk, jeżeli jest on botowalny to powinno wystarczyć coś takiego: Dla całego napędu: menuentry "MBR" { set root="(hd1)" chainloader +1 } Dla konkretne partycji sformatowanej w fat: menuentry "HD1 p1" { set root="(hd1,msdos1)" chainloader +1 } Oczywiście można też wczytać konkretny loader: menuentry "Grub4dos "{ setroot=(hd1,1) linux /boot/grub4dos/grub.exe } lub iso z live linux - np. dystrybucje ubuntu-podobne: menuentry 'linux' { setroot=(hd0,1) set isofile="/iso/linux.iso" loopback loop $isofile linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile liveimg noprompt noeject quiet splash -- initrd (loop)/casper/initrd.lz } Można też próbować ustawić fokus na konkretny napęd korzystając z komendy search z różnymi dodatkowymi opcjami, np. dla napędu o konkretnym identyfikatorze partycji: search --no-floppy --fs-uuid --set=root abcd-abcd Troszkę sprawa się komplikuje jeżeli grub jest zainstalowany w trybie efi, wtedy nie odpalimy z niego konfiguracji mbr (ani loaderów ani samego napędu), możemy ew. odpalić linuxa - większość współczesnych dystrybucji ma wkompilowany w jądro odpowiedni bootstrap. pzdr

Czy nowo utworzona wartość DWORD nie powinna przypadkiem mieć nazwy "Attributes"? Czy próbowałeś z zewnętrzną kartą dźwiękową (zewnętrzny DAC usb) raz - w takim przypadku dostaniesz prawie zawsze dostęp do sterownika asio (który z założenia jest sterownikiem low latency), dwa - nawet z mostkiem do windowsowego audio będziesz mógł zweryfikować czy to nie dźwiękówka (być może w kontekście acpi) stanowi problem. pzdr

Uzupełnienie. Ponieważ ostatnio musiałem w skrypcie dla windowsa wykryć tryb uruchomienia zbudowałem taki prost kod: @echo off @setlocal @for /f "tokens=2" %%G in ('bcdedit /enum {default} ^| find /i "path"') do (set FW=%%G) @if /i [%FW:~-4,4%]==[.exe] @echo Komputer uruchomiony w trybie "legacy" @if /i [%FW:~-4,4%]==[.efi] @echo Komputer uruchomiony w trybie "efi" @pause @endlocal pzdr

Windows w przypadku napędów USB obsługuje jedynie pierwszą partycję - w tym przypadku efi która z zasady jest ukryta dla systemu (są na niej pliki rozruchowe). Nie jest to zalecana konfiguracja dla napędu USB no ale to bez znaczenia (układ pachnie mi mac os-em). Należy usunąć partycję efi, przekonwertować pena na mbr i założyć pojedynczą partycję. pzdr

Masz system zainstalowany w trybie efi więc fixmbr nic nie zdziała, teraz kwestia co przywróciłeś testdiskiem partycje z jednoczesną konwersją na dysk mbr czy wolumeny gpt, w pierwszym przypadku ustawiona wcześniej sekwencja startowa jest nieprawidłowa, po pierwsze nie znajdzie odpowiedniego uuid po drugie nie wystartuje loadera .efi startując w trybie legacy. Proponuję z poziomu winpe wykonać polecenie: bcdboot c:\windows /s e:\ /f all gdzie c: jest literą przypisaną partycji z windowsem a e: litera przypisaną partycji z konfiguracją startową. Podanie "/f all" spowoduje utworzenie nowych sekwencji startowych zarówno dla trybu legacy jak i uefi. Jeżeli używasz standardowego instalatora windowsa to ważne jest w jakim trybie wystartowałeś płytę/pena (uefi czy legacy), instalator wykona instalację tylko w trybie w którym został odpalony. Dysk miedzy gpt a mnr można łatwo konwertować z poziomu diskparta (oczywiście jest to równoznaczne z ponownym wykonaniem komendy clean). Ograniczenia windowsowego instalatora można obejść przywracając system własnoręcznie z pomocą dism/imagex w tandemie z bcdboot - jak, szukaj na forum, parę razy to opisywałem. pzdr