<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Windows on すてきな太陽になりたい</title><link>https://blog.sei-yo.jp/categories/windows/</link><description>Recent content in Windows on すてきな太陽になりたい</description><generator>Hugo</generator><language>ja-JP</language><lastBuildDate>Tue, 02 May 2023 11:53:42 +0000</lastBuildDate><atom:link href="https://blog.sei-yo.jp/categories/windows/index.xml" rel="self" type="application/rss+xml"/><item><title>Unable to install Docker Desktop 4.19.0 (106363)</title><link>https://blog.sei-yo.jp/engineer/2023/05/posts/unable_to_install_docker_desktop_4190_106363/</link><pubDate>Tue, 02 May 2023 11:53:42 +0000</pubDate><guid>https://blog.sei-yo.jp/engineer/2023/05/posts/unable_to_install_docker_desktop_4190_106363/</guid><description>&lt;h3 id="概要"&gt;概要&lt;/h3&gt;
&lt;p&gt;以前インストールしていたDocker Desktop（4.3くらい）が起動しないと気付いたので、新しいものを入れようとしたらインストール失敗してしまい、その後試行錯誤してどうにかインストールできました。&lt;br&gt;
古いものをアンインストールしようにもアプリの一覧等にも表示されずおかしな状態になっていました。&lt;/p&gt;
&lt;h3 id="失敗時のログ"&gt;失敗時のログ&lt;/h3&gt;
&lt;p&gt;インストールに失敗していた頃のログは以下のような感じでした。&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;Version: 4.19.0 (106363)
Sha1: 
Started on: 2023/05/02 01:51:29.285
&lt;/code&gt;&lt;/pre&gt;</description></item><item><title>Docker Desktop for Windowsの導入</title><link>https://blog.sei-yo.jp/engineer/2020/01/posts/docker_desktop_for_windows/</link><pubDate>Sun, 12 Jan 2020 05:40:03 +0000</pubDate><guid>https://blog.sei-yo.jp/engineer/2020/01/posts/docker_desktop_for_windows/</guid><description>&lt;p&gt;Docker Desktop for Windowsを導入してみました。&lt;/p&gt;
&lt;p&gt;dockerコンテナを作って動かしたいのが目的です。 Windowsを使うのは、普段使っているOSがWindowsだからで、コンテナはLinuxのものを使います。 そうしたときに、docker Engineをどこで動かすかの選択肢があります。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Windows （Docker Desktop for Windows）&lt;/li&gt;
&lt;li&gt;Windows上のLinux VM（Hyper-VやVirtual Box上のLinux VMでLinux用のDocker Engineを動かす）&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;開発用にLinux VMを動かしているのでそちらでDockerを使っても良いのですが、わざわざVMを起動して使うのも面倒そうなのでWindows上で動かすことにしました。 ただ、Windows上で動かすと言っても、実際にはDocker用のLinux VMがHyper-Vを使って起動します。 そのため、自分でLinux VMを用意して動かすのと仕組みはそれほど変わりません。&lt;/p&gt;
&lt;p&gt;Docker Desktop for Windowsの場合、Docker ClientはWindows上で動きますが、Docker EngineはLinux VM上で動きます。 自分でLinux VMを用意して使う場合はDocker ClientもDocker EngineもLinux VM上で動きます。 コンテナそのものはどちらもLinux VM上で動きます。&lt;/p&gt;
&lt;p&gt;Docker Desktop for Windowsを使う場合、DockerfileやコンテナにコピーするファイルをLinux VMから利用できるようにする必要があります。 どのドライブをアクセス可能にするかは、settingsから設定できます。 なお、コンテナからマウントして使うようなデータ領域としてはWindows上の領域は不向きで、data volumeやdata containerを使う方が良いようです。これには二つの理由があって、一つはWindows上の領域はLinux上からみて、rwxrwxrwxのモードで見えます。もう一つは、SMBを使ってLinux VMに領域を見せる際、NOBRLオプションが付いているため、ロックができない場合がある点です。 これらは&lt;a href="https://docs.docker.com/docker-for-windows/"&gt;Docker Desktop for Windowsのドキュメント&lt;/a&gt;の最初の方（Shared drives）に書いてあります。&lt;/p&gt;
&lt;p&gt;と、ここまでやってから大事なことに気づきました。 開発用にLinux VMを動かしていますが、そちらはVirtual Boxを使っています。 Docker Desktop for WindowsはHyper-Vを使います。 これらの共存はできないので、どちらを使うか選ぶ必要があります。。つづく。。&lt;/p&gt;</description></item><item><title>vagrant up 失敗の原因究明</title><link>https://blog.sei-yo.jp/engineer/2019/10/posts/vagrant_up/</link><pubDate>Thu, 17 Oct 2019 01:00:00 +0000</pubDate><guid>https://blog.sei-yo.jp/engineer/2019/10/posts/vagrant_up/</guid><description>&lt;p&gt;vagrant upがなぜか失敗するのでその原因究明をしたときの話です。&lt;/p&gt;
&lt;h2 id="事象"&gt;事象&lt;/h2&gt;
&lt;pre&gt;&lt;code&gt;PS E:\vagrant&amp;gt; vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==&amp;gt; default: Box 'hashicorp/precise64' could not be found. Attempting to find and install...
 default: Box Provider: virtualbox
 default: Box Version: &amp;gt;= 0
==&amp;gt; default: Loading metadata for box 'hashicorp/precise64'
 default: URL: https://vagrantcloud.com/hashicorp/precise64
==&amp;gt; default: Adding box 'hashicorp/precise64' (v1.1.0) for provider: virtualbox
 default: Downloading: https://vagrantcloud.com/hashicorp/boxes/precise64/versions/1.1.0/providers/virtualbox.box
 default: Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
 default:
==&amp;gt; default: Successfully added box 'hashicorp/precise64' (v1.1.0) for 'virtualbox'!
==&amp;gt; default: Importing base box 'hashicorp/precise64'...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: [&amp;quot;import&amp;quot;, &amp;quot;\\\\?\\E:\\vagrant_home\\.vagrant.d\\boxes\\hashicorp-VAGRANTSLASH-precise64\\1.1.0\\virtualbox\\box.ovf&amp;quot;, &amp;quot;--vsys&amp;quot;, &amp;quot;0&amp;quot;, &amp;quot;--vmname&amp;quot;, &amp;quot;precise64_1571241203898_82313&amp;quot;, &amp;quot;--vsys&amp;quot;, &amp;quot;0&amp;quot;, &amp;quot;--unit&amp;quot;, &amp;quot;12&amp;quot;, &amp;quot;--disk&amp;quot;, &amp;quot;D:/VMimages/precise64_1571241203898_82313/box-disk1.vmdk&amp;quot;]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting \\?\E:\vagrant_home\.vagrant.d\boxes\hashicorp-VAGRANTSLASH-precise64\1.1.0\virtualbox\box.ovf...
OK.
0%...
Progress state: E_INVALIDARG
VBoxManage.exe: error: Appliance import failed
VBoxManage.exe: error: Code E_INVALIDARG (0x80070057) - One or more arguments are invalid (extended info not available)
VBoxManage.exe: error: Context: &amp;quot;enum RTEXITCODE __cdecl handleImportAppliance(struct HandlerArg *)&amp;quot; at line 957 of file VBoxManageAppliance.cpp
&lt;/code&gt;&lt;/pre&gt;</description></item><item><title>はじめてのWindows クラッシュダンプ解析</title><link>https://blog.sei-yo.jp/engineer/2019/08/posts/windows_1/</link><pubDate>Mon, 05 Aug 2019 00:24:38 +0000</pubDate><guid>https://blog.sei-yo.jp/engineer/2019/08/posts/windows_1/</guid><description>&lt;p&gt;Windows 10のマシンがブルースクリーンになってしまって、再発すると困るので見てみました。 ググってみるとちょっと見てみるところまでは簡単にできそうだったのでやってみました。&lt;/p&gt;
&lt;p&gt;結果はDPCウォッチドッグに引っかかっているみたい。（以下は、!analyze -vの抜粋）&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000000, A single DPC or ISR exceeded its time allotment. The offending
 component can usually be identified with a stack trace.
Arg2: 0000000000000501, The DPC time count (in ticks).
Arg3: 0000000000000500, The DPC time allotment (in ticks).
Arg4: fffff8003376e350, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains
 additional information regarding this single DPC timeout
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;そしてkの結果には以下の文字列が。&lt;/p&gt;</description></item></channel></rss>