「 VisualStudio 2012 」一覧

VisualStudio 2012 のリモートデバッグ


今更ですが VisualStudio 2012 のリモートデバッグが思いの外、進化していたことがわかりました。
リモートの環境で、リモートデバッグのモニターを起動しておくのは従来から変わらないのですが、今までの VisualStudio 2010 まではリモートに手動なりスクリプトなりでビルドした実行体や必要なファイルをコピーしていました。これが 2012 からはリモートデバッグの設定でできるようになりました。

この機能を使うためには、プロジェクトの設定を変更する必要があります。 構成マネージャーを開き
配置」の項目にチェックを入れる必要があります。デフォルトではここにチェックが入っていません

その後、プロジェクトのプロパティで、デバッグを 「ローカル Windows デバッガー」 から 「リモート Windows デバッガー」 に変更します。これらの各項目についてですが、以下のようになります。

  • リモートコマンド: ターゲットでの実行体のフルパスを記述
  • 作業ディレクトリ: ターゲットで配置した実行体のフォルダパス
  • リモートサーバー名: ターゲットのIPアドレスを記述
  • 配置するディレクトリ: ターゲットに実行体を配置するフォルダパス。作業ディレクトリと同じもの設定が無難
  • 配置するファイル: 実行体以外で転送したいファイルを列挙

これらを設定してみた図が以下のようになります。
vs2012_remote_dbg_config

これでビルド&実行の際に、リモートに必要なファイルが転送されて、即デバッグ開始できるようになります。
今までの一手間がずいぶんと楽になりました。VisualC++のデバッグランタイムもまた配置できるようで、わざわざスタティックリンク版を用意しなくてもよさそうなのも便利です。

その他

配置におけるプロセスですが、どのポートで通信してるかなと思ったら、 devenv からターゲットの 4016 ポートに向かって通信していました。 FW で引っかかるようだったらこのあたりを除外設定するとうまくいくかもしれません。
手元の環境では Norton Internet Security が入っていますが、上記の設定だけでうまく動作し、 FW の例外設定などは不要でした。



OpenCLのデバッガ(CodeXL)でトラブルに見舞われる


OpenCLのコード書きはおおよそわかってきたので、デバッガについて調べてみようと思います。やはり開発となるとデバッガは必要になってくると思いますし、AMDではCodeXLというツールがあるのでこれを試してみようと思います(ました)。
しかし!、このインストールして確認でとてもトラブルに巻き込まれてしまいました。結局OpenCLのデバッガに関しては検証できず終いです。

続きを読む


WindowsVistaとVisualStudio2012の罠


先日VisualStudio 2012自体の動作環境を調べてみましたが、それ以外にもまだ罠が潜んでおりました。
WindowsXPをターゲットとするリモートデバッグが出来ないのはよく知られた事実ですが、なんとWindowsVistaも同様にリモートデバッグが出来ない対象となっていました!

これに気付かずに、がんばってVistaでリモートデバッグを出来るようにと試行錯誤してました。
Update1以降を適用したとしても、XPがリモートデバッグできない対象であるようにVistaもダメなんでしょう。
Vista,XPをリモートデバッグの対象として使うなら、VisualStudio 2010はまだまだ手放せないようです。


Windows 8でXAudio2のトラブルに出遭う 解説編


前回の日記でふれたVisualStudio 2012 + XAudio2 + Windows 8 というコンボ発動で、アプリケーションを正常に起動出来ない!という罠にはまった内容を説明したいと思います。

実は、Windows 7で使用している(できる)最新のXAudio2は、 2.7 というバージョンのもので、これは DirectX SDK 2010 Juneに含まれています。またDirectXの再頒布ランタイムをインストールすることで導入できます。
一方、Windows 8で標準で使用するXAudio2は 2.8 というバージョンのものになります。これは VisualStudio 2012付属のWindows SDKを使用してアプリケーションを作成するとこちらを使うようになります。

標準状態の Windows 8 では、XAudio2は 2.8 のものだけが入っており、従来のDirectX SDKを使用していると 2.7のものを要求するために動作しません。
.Net framework をインストールした後で、DirectXのランタイムをインストールすると、Windows 8でも動作するようになりますが、これをアプリケーションを単に動かしたい人々がやるには手間もいいところです。
できるなら、そのままアプリケーションが動くのを目指したいところです。

これを表にするとこうなります。

DirectX SDKを使ってXAudio2 Windows 8ではそのまま動作しない
VS2012のWindowsSDKでXAudio2 Windows8では動作、Windows7では動かない

Windows7までの環境では対応したDirectX再頒布パッケージがあるのでそれをインストールすることができます。
ただそれらをインストールすること無しで XPから8まで、単一アプリケーションとしてサウンドを再生するには、実はDirectSoundを使用すると良さそうです(XPの標準状態でもDirectSoundは含まれていました)。

おそらくVista以降のDirectSoundはXAudio2より上位にレイヤーとしては位置付けられているようなので、
これを使うことでXAudio2に関係する依存関係を断ち切ってくれそうです。
ただし、DirectSoundは既にレガシーなAPIとなっているため、そのあたりが懸念事項でしょうか。
ただ互換性の点からOSから使用できない・削除されているわけではないため、XPから8まで一応使うことは出来るようです。

※ そのため単一アプリとして提供する際にはとても都合がよかったり。

DirectX9とXAudio2と。

D3DX関連のAPIもVS2012のWindows SDKに入っていないので、DirectX9+XAudio2という構成は VisualStudio 2012での開発にとってはなかなかの鬼門といえそうです。シェーダーのコンパイルはD3DXですし、XAudio2は今回のような問題があるし。

再頒布ランタイムをとりあえず強引にででもインストールさせるのであれば、DirectX SDK 2010 Juneを使って開発しておくでOKでしょう。
なるべくなら標準の状態で開発&配布したいと考えるなら、DirectX9やXAudio2を諦めて、OpenGLとDirectSoundを選択しておくと、余計なことを考えずともどこでも動く状態の物ができあがるように思います。

Windows Vista以降だけでよいというなら、WASAPI も選択肢に上がってくるかと思いますが、これは使うのが大変なので手軽にという点も考慮するなら、やはり情報も多いDirectSoundでお茶を濁しておくのが手っ取り早いでしょう。

参考元
XAudio2 Versions


Windows 8でXAudio2のトラブルに出遭う


VisualStudio 2012を使っていたら、Windows8でのXAudio2で問題に遭遇したのですが、
この件で、有名な吉野屋テンプレがうまく使えそうだと閃いたためちょっと貼ってみます。
ちゃんとした説明は次回に行いたいと思います。

では、どうぞ。

昨日、XAudio2 を使ったアプリを Windows 8 で動かしたんです。Windows 8。
そしたらなんかアプリが起動出来ないって言われるんです。

で、よく見たらヌルポでアクセス違反、とかのようなんです。
もうね、アホかと。馬鹿かと。

お前らな、XAudio2 引き如きで普段使わない Windows 8に来てんじゃねーよ、ボケが。
XAudio2 だよ、XAudio2。

なんかDirectX9とかもいるし。DirectX9 + XAudio2でWindows 8か。おめでてーな。
よーしパパ、プログラムをWindows 8対応しちゃうぞ、とか言ってるの。もう見てらんない。
お前らな、Windows SDK やるからその席空けろと。

Windows 8 対応ってのはな、もっと殺伐としてるべきなんだよ。
OS環境ごとにプログラムを用意しないで、
単一プログラムがそのまま動くか動かないか、そんな雰囲気がいいんじゃねーか。
女子供は、すっこんでろ。

で、やっと座れたかと思ったら、隣の奴が、WASAPI で、とか言ってるんです。
そこでまたぶち切れですよ。

あのな、WASAPI なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、WASAPI、だ。

お前は本当にWASAPIを使いたいのかと問いたい。問い詰めたい。小1時間問い詰めたい。
お前、WASAPI って言いたいだけちゃうんかと。

Windows 8通の俺から言わせてもらえば今、Windows 8での最新流行はやっぱり、
DirectSound、これだね。

素のDirectX9+DirectSound。これが通の頼み方。
DirectSoundってのは古くからあるDirectXのサウンド担当。そん代わり今やオーバーヘッドが多め。これ。

で、素のDirectX9(D3DXとかナシ)。これ最強。

しかしこれを頼むと次からマイクロソフトにマークされるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、OpenGL + DirectSoundでも使ってなさいってこった。

※ 注意: OpenGL + DirectSound なら今や多くの環境でそのまま動くことでしょう。


VisualStudio 2012 でのプロジェクトの依存関係


VisualStudioではプロジェクトの依存関係を設定すると、その設定された依存先が出力するライブラリを暗黙的にリンクしてくれる機能が、かつてはありました。VisualStudio 2008のころにはよくお世話になりました。
しかし、VisualStudio 2012で同じことをやってみても、どうもその暗黙的なリンク機能が働かないようです。
正確には、従来の手順だけでは働かないということだったのですが、今回はこの方法を記事にしたいと思います。
また今回の内容は 2010からの挙動変更のようです。

  1. 従来通り、依存関係を設定した複数のプロジェクトから構成されるソリューションを作成します。
  2. この中のアプリケーション側のプロジェクトのプロパティを開きます。
  3. 共通プロパティを開き、「新しい参照の追加」ボタンを押し、依存先のプロジェクトにチェックを入れる

この手順を行うことで、従来の挙動のような暗黙的なリンクを行うことが出来ます。

なお注意点として、この参照の追加で自分自身をいれないこと。入れてしまうとよくわからないエラーが発生してしまいます。


VisualStudio 2012とDirectX SDK 再び


以前の日記にて、Visual Studio 2012 と DirectX SDK (2010June) を使って開発する際の手順を書きましたが、
どうやら最近ではマイクロソフトのほうに注意書きが用意されているようです。

そのページがこちら(http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275(v=vs.85).aspx)です。

基本的には、DXSDK_DIRのインクルードとライブラリを標準のものより優先されるようにすること、という以前の日記情報と同じです。
ただ上記URLの中身ではそれよりももうちょっと踏み込んで、手順が書いてありました。

  • コンフリクトするので DXGIType.h をインクルードしているコードを修正する(インクルードしないように)。
  • テクスチャ関連は DirectXTex や DirectXTK といったものを利用するように検討すること
  • 算術に関しては D3DX から DirectXMath の実装へ切り替えを検討すること
  • XInput や XAudio2 を使う場合には要注意

気になった点をざっと列挙してみました。
XAudio2は厄介そうです。 使用するDLLがVS2012とDXSDKとで異なってしまうようで・・・。
どこでも動くように、というならば DXSDKのものをつかわないといけない、ということのようです。


Windows8時代のKernel Debugging USB 3.0編


前回はネットワーク経由によるWindows Kernel Debugの接続方法を説明しました。今回は USB 3.0によるカーネルデバッグの設定方法となります。

環境

ホスト
Windows7 もしくは Windows8 がインストールされており、WinDbgが起動可能なように準備されていること。
VisualStudio 2012 + WDK の環境もOK

※ 後述しますが、Windows8のほうが問題がないので、望ましいです。Win7でも概ね問題なく使えるのですが。

ターゲット
Windows8がインストールされたPC。

共通
試す内容から当然ですが、両者 USB 3.0のポートを備えており、ドライバのインストールが完了していること。
自分の実験環境では、ターゲットにはそもそも USB 3.0 をマザーボードに持っていなかったため、玄人志向の USB 3.0 拡張ボードをさして本実験を行っております。

USB 3.0経由のカーネルデバッグの設定

USB 3.0でのカーネルデバッグ設定方法を説明していきます。
ターゲットの(管理者の)コマンドラインでbcdeditを起動して、設定するだけで終了です。簡単です。

c:\>bcdedit /dbgsettings usb targetName:usb3
c:\>bcdedit /debug on

targetName:以降の名前については、任意の物が使用可能です。設定したら再起動を行います。
このときに ホストとターゲットをUSB 3.0のケーブルで接続しておきます。

続いてホスト側の設定です。
WinDbgなら起動して、メニューから、 File / Kernel Debug を選択し、USBタブを開いて、TargetNameの部分に、先ほど指定した usb3 を入力して待ち受けるだけです。

接続されると以下のようにログが出てきます。(ここからスクリーンショットはWindows8のホストに切り替えてます。ターゲットのWin8ではない点に注意)

ターゲットを再起動してもこの通り(注意点参照)。

うまく動いているようです。

気になる点は、このようにうまく動いているのにもかかわらず、Debuggee not connected と出ているタイミングがあることや、
デバイスマネージャー上で USB 2.0 のデバッグデバイスだ と主張している点です。そう見えているのだろうか…。

注意点

たまにUSB3.0のチップが複数搭載されているケースがあります。この場合、自分が試した範囲では Intelチップ側のほうが正常に動くようです。また拡張ボードで使用しているチップは、Renesas の μPD720202 チップでした。

また、Windows7をホストとして使用している場合、現時点までにわかっている妙な不具合として、以下の点があります。

  • ホストでデバッグ接続したまま、ターゲットを再起動すると次回起動時にパケット送受信エラーのようになる
  • この場合、ホストの方も再起動するまで使用不可能になる
  • ターゲットを再起動する際には、ホストのほうのデバッグ接続を一度切っておけば、問題はなさそうに見える

Windows8だとターゲットを再起動しても問題なく再コネクション行って以下のようにログが出てきます。

まとめ

Windows8ではUSB 3.0によるカーネルデバッグ接続も受け入れてくれるので、選択肢が広がりました。
今のところ Networkと並んで有力候補となるのではないかと考えています。
上記で何気なく説明しているケーブルが実はくせ者だったりするので、これについて次回以降ちょっと記事にしたいと思います。

設定の情報元
マイクロソフトのSetting Up Kernel-Mode Debugging over a USB 3.0 Cable Manually


Windows8時代のKernel Debugging


最近、WindowsのKernel Debugが出来るように準備を進めていました。古い人の話だと、カーネルデバッグはシリアル接続で!という話みたいですが、今やその接続方法も色々と選べるようで、しばらくこの接続方法について記事を書いておきたいと思います。

なお、自分は最近始めたばかりのにわかです。Kernel Debugging で出来ることはこれから学んでいこうと思っています。

さて、Windows8 になってさらにカーネルデバッグの接続方法は増えました。
特に、ネットワーク経由によるもの、USB 3.0 経由によるものの2つが増えました。
USBは 2.0 なら従来からサポートされていたようですが、特殊な機器が必要となっていたようです。
またこれが日本では販売しておらず、輸入の形で入手するしかなかったそうです。

他の方法では、COMによるシリアル接続、IEEE1394による接続、とあるようです。
ただ最近は両者のインターフェースを備えるマザーボードも減ってきているし、将来を考えるとこの方法は未来が無いなと思います。
Microsoftが Windows8 で出来るようにしてきた2つの方法はしばらくはメインの方法として生き残っていくのではと期待しています。

Windows8 をインストールして、デバイスマネージャーを見てみると実は、Microsoft Kernel Debug Network Adapter というものが存在しています。
これがまさにカーネルデバッグ時に使えるアダプタとなります。

環境

ホスト
開発者が操作するPC側をホストと呼びます。こちらは Windows7 を想定して、VisualStudio 2012 がインストールされているとします。
WDKがインストールされているか、WinDbgが使用可能状態になっていることも条件です。
ターゲット
デバッグされる側のPCのことをここではターゲットと呼びます。Windows8 がインストールされているものとします。

ネットワーク経由のカーネルデバッグの設定

LANでのカーネルデバッグを説明します。
ターゲットの(管理者の)コマンドラインでbcdeditを起動して、設定するだけで終了です。簡単です。

c:\>bcdedit /dbgsettings net hostip:ww.xx.yy.zz port:PortNo
Key=**********************************
c:\>bcdedit /debug on

上記のコマンドを実行の際に、ネットワークのキー情報が出力されます。これをメモしておく必要があります。
hostipにはホストPCのIPアドレスを記入し、PortNo の部分にはポート番号(50000以降の値にしておく)を指定しておきます。
この設定は次回の起動から有効になります。

ただこの設定が有効化されると対象となる物理的なネットワークアダプタは見えなくなる点に注意が必要です。
普段の通信には、Microsoft Kernel Debug Network Adapter が有効化された別アダプタが見えてくることになります。
こちらにIPをきちんと割り当てておけば、Windowsのファイル共有も使えますし、問題にはならないでしょう。
問題になるとすれば、実は対応するネットワークアダプタには制限がある、ということです。
こちらのほう(対応リスト)に対応しているチップセットが書いてあります。

とりあえず最近のマザーボードにのっていることの多い Realtek製が含まれている点で問題にはなりにくそうです。またIntelの入手しやすいチップも対応しているようなのでこれも問題ないでしょう。
RTL8168, RTL8169, RTL8136, ICH8からICH10とか、Intel Gigabit CT desktop adapterとか使える点がいいですね。

ホスト側では WinDbg を起動して、ターゲットの接続待ち状態にしておきます。
NETタブを開いて、先ほどメモしたKeyを入力し、ポート番号をあわせておきます。

問題なければ、接続が確立されWindowsの起動とともに情報が出てくると思います。
VisualStudio2012と現在のWDKは統合されて便利になったようで、わざわざWinDbgを起動しなくても Visual Studio からカーネルデバッグもできるようになっているようです。

この場合には、”プロセスにアタッチ” を選び、トランスポートに Windows Kernel Mode Debuggerを選びます。
そして、検索ボタンを押して出てくるダイアログで、Add New Computer を選択します。
ターゲットの設定は既に終わっているので、その後の画面ではManually Configure … を選んでおきます。

その後の設定画面では、下記の画面のようになるので、キー&ポート情報を入力します。
ここでのHost IPはこのVisual Studioを起動しているPCのアドレスとなるため間違えないようにします。

まとめ

特殊な機器を不要としてのカーネルデバッグが出来るようになってきたのは、これから始める自分みたいな人にとっていいことだと思います。
さらにはネットワーク経由なので、ちょっと物理的に機器同士が離れていても問題なくなったのがすばらしい。
ちょっと手元の機器で試してみて、今のところどれでも動いているようなので相性とか問題はないのかもと思います。

今回説明しなかった USB 3.0 についても近いうちに記事にしたいと思います。
日本語ではなかなか記事がないため苦労しましたが、ネタとしてはなかなかおもしろいためご期待下さい。

今回の設定方法元
Microsoftのページ: Setting Up Kernel-Mode Debugging over Network Cable Manually