Azure DevTest Labs および Azure VM の自動シャットダウン機能の設定時刻について

こんにちは、Visual Studio サポート チームです。 今回は、Azure DevTest Labs および Azure VM の自動シャットダウン機能 (*1) を設定した時刻と、実際にシャットダウンが行われる実行タイミングの関係について、ご案内します。 設定内容によっては、意図したタイミングでシャットダウンできないケースがありますので、本稿が参考になりましたら幸いです。   (*1) Azure DevTest Labs は、アプリケーションのテスト環境となる VM を Azure 上に構築・管理し、アプリケーションのデプロイプロセスにテスト環境のプロビジョニングを組み込んで、テスト環境の構築に要するコストを削減するためのサービスです。Azure VM の自動シャットダウン機能も、DevTest Labs から提供されています。 Azure DevTest Labs とは https://docs.microsoft.com/ja-jp/azure/lab-services/devtest-lab-overview   現象 DevTest Labs または Azure VM で、自動シャットダウンの設定したにも関わらず、設定当日に対象 VM の自動シャットダウンが実行されない場合があります。   原因 本現象は、自動シャットダウン機能の想定された動作に依存して発生している可能性があります。 DevTest Labs および Azure VM の自動シャットダウン機能では、設定を行った時点から所定の時間間隔をあけて実行される必要があり、この間隔が短いと当日のシャットダウンは行われず、翌日の当該時刻にシャットダウンが実行される動作となります。 この所定の時間間隔の目安は、通知機能 (Email または Webhook) の設定に応じて以下とおりとなっています。   通知機能を有効にしている場合 : 31 分間 通知機能を無効にしている場合 : 1 分間   以下に、具体的な設定と、想定される結果の例を示します。  …


Visual Studio 2015 および Visual C++ 2017 のリンク時のコード生成における最適化の不具合について

こんにちは、Visual Studio サポート チームです。 今回は、Visual C++ 2015 および Visual C++ 2017 で確認されている、C++ プロジェクトのリンク時のコード生成における最適化の不具合についてご案内します。 なお、この事象については報告が非常に少なく現在も修正に向けて調査中ですが、進展があり次第この記事を更新する予定です。   現象 以下の条件を満たす場合に、仮想関数呼び出しが正常に行われず基底クラスのメンバー関数が実行される場合があります。 速度優先の最適化 (/O2 オプションもしくは /Ox オプション) を指定している。 リンク時のコード生成 (/LTCG オプション) を指定している。 プログラム全体の最適化 (/GL オプション) を指定している。 仮想関数の呼び出しと仮想関数の実装が異なるバイナリ間で行われている。   原因 本現象は弊社製品の不具合に起因して発生しています。 Visual C++ コンパイラーおよびリンカーは、呼び出される仮想関数がコード生成時に静的に決定でき、かつ最適化によるパフォーマンスの向上が見込めると判断した場合、devirtualization と呼ばれる仮想関数呼び出しを直接呼び出しに置き換える最適化を行います。 リンク時のコード生成が指定されている場合、仮想関数の呼び出しと仮想関数の実装が異なるバイナリ間で行われている場合も devirtualization が試みられますが、仮想関数ではなく基底クラスの関数が呼び出されるコードが生成される場合があります。   回避策 以下のいずれかの方法でリンク時のコード生成における devirtualization の最適化を無効化することで、この問題を回避できます。 コンパイラー オプションで /d2notypeopt を指定する リンカー オプションで /d2:-notypeopt オプションを指定する…


.NET Framework のネイティブ イメージが無効になる状況と考えられる影響について

こんにちは、Visual Studio サポート チームです。 .NET Framework のライブラリは中間言語 (MSIL) 形式のアセンブリとして提供されていますが、これらは事前にコンパイルされるか、アプリケーションの実行時に JIT コンパイルされて機械語に変換され、プログラムから利用されます。 今回は、Windows Update の適用などに伴い .NET Framework のネイティブ イメージが無効になり再作成が行われる動作と、考えられる影響などについてご案内します。   現象 Windows Update や .NET Framework の更新プログラムの適用後、.NET Framework を使用するアプリケーションやサービスの動作が遅くなる場合や、CPU 使用率が高騰する場合があります。 PowerShell など、 .NET Framework 上で動作するスクリプトをホストするプロセスも同様の事象が発生する場合があります。 なお、下記の KB で案内しているとおり、32 ビットの .NET Framework に比べて 64 ビットの .NET Framework のほうが JIT コンパイルが必要となることに伴う影響は大きい傾向があります。 64 ビットの .NET Framework アプリケーションの起動に時間がかかる https://support.microsoft.com/ja-jp/help/2833666  …


プロジェクト参照を含むソリューションのビルド時に、変更のないプロジェクトに対してもリビルドが行われる

こんにちは、Visual Studio サポート チームです。 今回は、Visual Studio でソリューションをビルドする際のリビルドの動作に関して、ご留意いただきたい内容をご紹介します。   現象 プロジェクト参照 (*1) を含むソリューションを Visual Studio で開き、ソリューション構成 (Debug/Release など) を切り替えてビルドを行うと、プロジェクトに変更が加えられていなくてもプロジェクトがリビルドされる場合があります。   (*1) “プロジェクト参照” とは、あるプロジェクトから、同一のソリューションに含まれる別のプロジェクトを参照する参照方法であり、被参照側プロジェクトに変更があると、そのプロジェクトだけでなく参照側のプロジェクトもビルドが必要とみなされます。複数のプロジェクトを 1 つのソリューションで同時に開発する場合に便利な参照形式です。 これに対し、DLL を直接参照する “アセンブリ参照” は、サードパーティから提供されている DLL や、社内共通の共通ライブラリとして提供されている DLL など、対象のプロジェクトと被参照 DLL が別々に開発される場合に利用される参照方法です。   原因 本現象は Visual Studio の想定された動作に基づく制限事項です。 プロジェクト参照を含むソリューションでは、Visual Studio がビルドの要否を判断するロジックの制約から、直前にビルドされたソリューション構成から変更が生じた場合に、プロジェクトを参照している側のプロジェクトに対してリビルドが行われます。(*2) なお、”直前にビルドされたソリューション構成” の情報は、Visual Studio の起動中は Visual Studio 内に記憶され、Visual Studio の終了後は .suo ファイル (*3)…


Visual C++ 2015 以降のバージョンの再頒布可能パッケージにおけるインストールの前提条件

こんにちは、Visual Studio サポート チームです。 今回は、最近多くのお客様からお問い合わせをいただいている Visual C++ 再頒布可能パッケージのインストールに必要な前提条件についてご案内します。   以前のブログ記事でもご案内していますが、Visual C++ 2015 以降のバージョンの C ランタイム (CRT) は、汎用 C ランタイム (UCRT : Universal C Runtime) とそれ以外のランタイムで構成されています。Visual C++ 2015 再頒布可能パッケージをインストールすると、これらのランタイムがすべてインストールされます。 ここで、UCRT は Windows 10 以降の OS は既定でインストールされているものになりますが、Windows 10 より前の OS にインストールするためには、対象の環境に前提となる KB が適用されている必要があります。 このため、例えば、新規にセットアップしたばかりの Windows 8.1 に Visual C++ 2015 再頒布可能パッケージをインストールしようとすると、UCRT の前提条件となる KB が適用されていないために、インストール エラーとなることが想定されます。 Visual C++…


ClickOnce アプリケーションのインストールや更新の後に発生する場合があるアプリケーション起動時のエラーについて

こんにちは、Visual Studio サポート チームです。 今回は、ClickOnce アプリケーションのインストールや更新後に発生する場合がある、アプリケーション起動時のエラーとその対処方法についてご案内します。 当ブログの下記の記事でも ClickOnce アプリケーションの起動時のエラーについて取り扱っていますが、今回は、この他によくお問い合わせをいただく既知の問題についてご案内しています。 ClickOnce 起動時のエラーについて https://blogs.msdn.microsoft.com/jpvsblog/2011/08/05/clickonce/   現象 ClickOnce アプリケーションをインストールした場合や更新した場合に、以下のようなエラー ダイアログが表示され、アプリケーションの起動に失敗する場合があります。 “詳細” ボタンを押下すると、エラーの状況に応じて以下のようなエラーの詳細が記録されている場合があります。 ※ 当記事の原因に該当する場合、多くのケースではスタック トレース上に ComponentStore.ActivateApplication が現れますが、スタック トレースの内容など詳細は .NET Framework のバージョンにより異なる可能性がございます。また、代表的なエラー メッセージを挙げており、すべてのパターンを網羅するものではございませんので予めご了承ください。 必要なレジストリ キーが見つからなかった場合 この操作中に次のエラーが検出されました。 * [2018/02/19 14:35:33] System.ArgumentException – 値が有効な範囲にありません。 – ソース:System.Deployment – スタック トレース: 場所 System.Deployment.Application.NativeMethods.CorLaunchApplication 場所 System.Deployment.Application.ComponentStore.ActivateApplication 場所 System.Deployment.Application.SubscriptionStore.ActivateApplication 場所 System.Deployment.Application.ApplicationActivator.Activate 場所 System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation 場所 System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker…


OLE パッケージ オブジェクトを含むドキュメントを開くと GDI オブジェクトが増加する

こんにちは、Visual Studio サポート チームです。 今回は、OLE パッケージ オブジェクトをプログラムから利用した場合に発生する問題についてご案内します。   現象 アプリケーションから OLE パッケージ オブジェクト (*1) を含むドキュメントを開いて閉じる操作を繰り返すと、アプリケーションの GDI オブジェクトの使用量が増加します。 増加量は僅かであるため、ほとんどのアプリケーションではこの問題が影響することはありませんが、パッケージ オブジェクトを含むドキュメントを、開いて閉じる動作を繰り返すようなアプリケーションでは、GDI オブジェクトの総量がプロセスごとに割り当てられた上限 (既定で 10,000) に達し、それ以降の GDI オブジェクトの生成に失敗して描画処理に問題が生じる場合があります。   (*1) パッケージ オブジェクトは、他のファイルやプログラムなどを OLE オブジェクトとしてドキュメントに挿入できるようにするためのオブジェクトです。   パッケージ オブジェクトの挿入 原因 本現象は、OLE パッケージ オブジェクトを管理する Windows OS のパッケージ管理コンポーネント (packager.dll) の不具合に起因するものです。 本コンポーネントでは、パッケージ オブジェクトごとにタイトルを表示するためのフォント オブジェクトを生成しますが、ドキュメントを閉じてもこのフォント オブジェクトが解放されないため、ドキュメントを開いて閉じる操作を繰り返すとフォント オブジェクト (GDI オブジェクト) が増加し続ける結果となります。   対応状況 マイクロソフトでは米国本社の開発部門でも本不具合を確認していますが、現時点では修正プログラムなどは提供されておらず、提供の予定はありません。 パッケージ…