サポートの職場から

みなさんこんにちは、Platform SDK (Windows SDK) サポートチーム マネージャーの小山田です。当チームのBlogをお読みいただきありがとうございます。メンバーから私もBlog書いてはどうかと誘ってもらいましたので、今回は技術的な話題はちょっとお休みして、弊社サポートにお問い合わせを頂いてからご回答を差し上げるまでの流れについてご紹介させていただきたいと思います。 私たち技術サポート部門は、浮世の誘惑に惑わされず技術に集中しなさいという会社の配慮か(?)品川本社とは少し離れた東京都調布市にある「マイクロソフト調布技術センター」に拠点を構えています。先日久しぶりに品川本社に行ったのですが、オフィスで和服姿の男性が歩いているのを見かけ、カルチャーショックを受けました。この辺には“鬼○郎”や“一反○めん”のモニュメントはあるのですが、さすがにファッションにおいては品川に後れを取っている感じです。 そんな環境にいる私達は日々多くの技術的なお問い合わせに対応させていただいていますが、お問い合わせをいただいてからご回答を差し上げるまでの大まかな流れは次のようになっています。   1. 担当者の決定 お問い合わせをいただく毎に、技術エリアに応じて適切な担当エンジニアを決定します。例えば、Windows OSのお問い合わせとして受領しても内容を精査したらInternet Explorerの問題だと考えられる場合には、IEのエンジニアを割り振ります。   2. 担当者エンジニアからのご連絡 担当エンジニアからお客様に電話またはメールで最初のご連絡をいたします。   3. お客様とゴールを設定 お客様と一緒に調査のゴール、調査方針、スケジュールを決定します。ここではお問い合わせの内容だけではなく、お問い合わせの背景や問題を取り巻く状況もお伺いさせていただくことがあります。これは、例えば、回避策を取るにしてもどういった回避策なら取れるか、あるいは取れないかをお伺いできれば、回避策が取れそうな方向に絞って調査方針を検討できるからです。ここでお客様の問題と諸制約をしっかり把握することが早く正確なご回答を差し上げるためのカギとなりますので、ご協力いただけますようお願いいたします。また、問題を再現するためのサンプルプログラムの作成をお願いする場合があります。これもお客様の問題を正しく把握するために必要ですのでご協力をお願いいたします。不明な点があれば何なりと担当エンジニアにお問い合わせください。   4. 調査  お客様と設定したゴールに向けて、途中経過を随時ご報告しながら調査を進めます。調査方針の決定や調査は、担当エンジニアだけではなくリーダーや関連技術に詳しいエンジニア、時には海外のエンジニアも入って行います。担当エンジニアが不在の時にも滞りが出ないよう必ずバックアップ エンジニアもつき、調査を進めていきます。   5. 調査完了 調査結果が出たらお客様にご連絡します。通常はメールにて内容をご連絡した後、お電話にて補足説明をさせていただきます。お客様から調査終了のご了解が得られたらお問い合わせ終了となります。   このようにいつもスムーズに進められればよいのですが、中には不具合や仕様によりお客様のゴールをずばり達成できない場合もあります。その場合は担当エンジニアだけでなくチーム一同で頭を悩ませ何とか解決する方法がないか検討するのですが、回避策はあってもお客様側で採用できないないケースもあり、そのような時は夕日に向かって叫びたくなります。(ちょっと古いですね。。イマドキの人は、どこに向かって叫んでいるのでしょうか?) 一方、問題が無事解決できてお客様にもご満足いただいたとのお言葉を頂戴できた時が、サポート エンジニアをやっていてよかった!と思える瞬間です。担当エンジニアだけでなく、チーム一同幸せな気持ちになります。 難しい問題だけでなく、ちょっとした調査にも私たちをご利用いただければと思います。お客様は本業に専念頂き、技術的な調査はお任せいただけるような開発のパートナーでありたいと願っています。「MSDN サブスクリプション特典」や「BizSpark特典」など、弊社が提供している製品やサービスに付帯した技術サポート特典もいくつかありますので、ぜひ期限切れになる前に有効にご利用ください。 これからマイクロソフトのサポートの利用を検討したい、あるいは現在利用しているがもう一度内容を確認したいという場合には、サポートのサイトをご参照ください。サイトをリニューアルして内容を充実させましたのでご一読いただければ幸いです。 製品の開発期間はせいぜい数年です。あの巨大なWindowsでも数年サイクルで出荷されています。しかし、私たちサポート部門は製品が出荷された後もライフサイクルが終了するまでずっとサポートをご提供し続けます。製品開発部からバトンタッチされたその責任を忘れず日々精進してまいりたいと思いますので、これからもどうぞよろしくお願いいたします。


消えないファイルの話

こんにちは。Windows SDK のサポートをしています masanish です。 今回は、ファイルの削除についてしばしばお問い合わせいただく話題をご紹介します。     ファイルが消せない いらなくなったファイルを ”完全に” 削除するには、コマンドプロンプトの Del コマンドや エクスプローラー で [Shift] + [Del] を利用しますね。ところが、ファイルを削除しようとしても、消せない、消えてくれないという経験はないでしょうか。この理由として2つのパターンがあります。   1つは、そもそもそのファイルを削除する権限を持っていない場合です。同じコンピュータを利用している別のユーザが作成したファイルとか、もともと Windows を動かすために必要なファイルだったりすると、消されると都合が悪いですね。Windowsでは、それぞれのファイルについて、誰がファイルを消す権限をもっているかどうか決められているので、許可されていない場合にはファイルを消すことができません。   もう1つは、そのファイルが使用中の場合です。使用中というのは、プログラマ的な表現にすると、別のプログラム(プロセス)そのファイルを開いている場合です。だれかが、ほかで使っているいるのに、そのファイルが突然消されてしまうとやっぱり具合が悪いですね。この場合もファイルを消そうとしても失敗します。いずれも、ファイルを消せない理由があるのです。     (消せない…使っているのはだれかぁ)     「ファイルは消せた」 はずだが、まだ残っている…   さて、今回紹介するのは、もうちょっと変わった現象です。というのは、 ファイルの削除は成功します(ですから、エラーは発生しません) でも、ファイルはまだ残っています。たとえば、コマンドプロンプトで Dir や Explorer で [F5] をしてフォルダ中身をみるとちゃんとファイルはあるのです。 ところが、しばらくするとそのファイルがなくなっている。 これは、ファイルの削除を行った際に、そのファイルの削除が直ちに行われず保留されている状態です。で、どのようなときにファイルの削除が「保留」されるかというと、別のプログラム(プロセス)でまだオープンされている場合です。 「えっと、ちょっと待った。別のファイルでオープンしていると、そのファイルって消せないのじゃないの?ちょっと前にそう書いてありますよね。」 はい、そうです。別のプログラムが使用中の場合に、ファイルを削除できるかどうかは、そのファイルの開き方によるのです。     ちょっと実験   では、このようなファイルの削除が遅延される現象をみてみましょう。    1.ここでは、C++ でのプログラムを用意します。以下のプログラムを コンパイルしてopenfile.exe という名前で作成します。…


重箱の隅のデバッグ(2) – エラーの意味を探る

皆さんこんちは。Platform SDK チームの Chiharun です。 「重箱の隅のデバッグ」シリーズ第 2 回は API から返されたエラーコードの定義を調べる方法についてご紹介します。 プログラムコードの中で API を呼び出して、API の戻り値をチェックすることによって API が正常に完了したか確認することができます。 SDK や DDK/WDK を使ったことのある方は以下のようなヘッダファイルをソースファイルに直接的あるいは間接的にインクルードしてヘッダファイルで定義されているエラーコードの定義名を参照したことがあることでしょう。 winerror.h ntstatus.h プログラムを WinDbg でデバッグする場合にも API の返すエラーの値を調べることは良くあります。 例えばある値が API の戻り値として返された場合に、その値を上記のヘッダファイルに対して文字列検索で調べるといった場合があります。 私も以前はヘッダファイルを検索してエラー値の定義名を求めていました。 現在は別の方法でエラーに該当するヘッダファイル側の定義名を求めています。 理由としてはマイクロソフトの提供するすべての製品で利用されている API の戻り値を上記の 2 個のヘッダファイルで網羅していないため、検索してもヒットしない場合があるからです。 Err.exe – エラーコードを見つけるツール今回ご紹介するツールは err.exe と呼ばれるコンソールプログラムです。 マイクロソフトのダウンロードセンターから入手することができます。 Microsoft Exchange Server Error Code Look-uphttp://www.microsoft.com/download/en/details.aspx?id=985 ダウンロードセンターからダウンロードした自己解凍プログラム Err.EXE を実行すると、以下のファイルを展開することができます。 あとは Err.exe に Path を通せばコマンドコンソールから利用する準備が整います。…


WinSock (Windows Sockets) API で IPv4/IPv6 デュアル スタック プログラミングに挑戦!!(TCPクライアント編)

Platform SDK (Windows SDK) サポートの小泉です。みなさま、IPv4 アドレスが枯渇するといった話題が出てから何年も経ちましたが、IPv6 対応は既にお済でしょうか?「まだ IPv4 が使えるし、IPv6 への改修をしたらIPv4 対応しかしていない古いネットワークでは自社アプリケーションが使えなくなってしまう。IPv6 対応はまだ早いかな。。。」と心配されている方!!IPv4 ネットワークにも IPv6 ネットワークにも対応できるWinSockのプログラミング方法があったとしたら如何でしょう?今のうちに対応していれば、エンドユーザ様にも「自社のアプリケーションは、旧来の IPv4 ネットワークにも、最新の IPv6 ネットワークにも両方対応しております。将来、世の中が IPv6 ネットワークに完全移行してもアプリケーションに対する移行コストは 0 です。」と胸を張って言えますね。という事で、今回は「WinSock (Windows Sockets) API で IPv4/IPv6 デュアル スタック プログラミングに挑戦!!」と銘打って、IPv4/IPv6 の両方に対応したプログラミング方法をご紹介いたします。 1.まずはIPv4対応WinSockプログラムのおさらい まずは、一般的な IPv4 対応 WinSock プログラムのおさらいから始めましょう。ほとんどの IPv4 対応WinSockプログラム(クライアント側)は以下のような流れになっているかと思います。以下の例を見てもわかるとおり、IPv4 アドレスを直接指定しており、これでは IPv4 通信しかできませんね。  1)  WSAStartup API でソケットを初期化します例:WSAStartup(MAKEWORD(2, 2), &wsaData); 2)  Socket API で利用する IPv4 アドレスファミリとプロトコルを指定して、ソケットハンドルを作成します例:SOCKET…


重箱の隅のデバッグ(1) – インポートセクションで設定するブレークポイント

皆さんこんにちは。Platform SDK チームの Chiharun です。  「重箱の隅のデバッグ」シリーズ第 1 回としてデバッグ関連のトピックをご紹介します。ここで利用する WinDbg デバッガはマイクロソフトが公開している高機能なデバッグツールです。入手方法については、以下のURLをご覧下さい。 デバッグ ツールとシンボル: はじめにhttp://msdn.microsoft.com/ja-jp/windows/hardware/gg462988 インポートセクションについて日々の仕事で提供元が不明だったり、デバッグシンボルの存在しないプログラムをデバッグする状況は多々あります。そのような場合にデバッガコマンドでインポートセクションを確認することによってプログラムが呼び出す API の概要を把握し、インポートセクションをライブデバッグで利用する方法について説明したいと思います。 一般的にプログラムが動作する時にメインの EXE プログラム単体ですべての処理を実行することはありません。 必要に応じてプログラムが利用する API の関数本体が実装された外部の DLL に存在する関数を呼び出します。 メインの EXE プログラムは関数へのポインタが設定されたインポートセクションから関数のアドレスを取得して他の DLL に存在する関数を呼び出します。 Windows OS がプログラムをロードする時に、プログラムが参照する外部の DLL の API のアドレスをプログラムが参照できるようにするため、プログラムのインポートアドレステーブルを外部の DLLに存在する API の関数アドレスで初期化します。関連する情報についてはMSDNマガジンの2002年2月号で解説された記事がありますのでリンクをご紹介します。 MSDN Magazine 2002 February – An In-Depth Look into the Win32 Portable Executable File Formathttp://msdn.microsoft.com/en-us/magazine/cc301805.aspx では本題に戻ります。インポートセクションの情報をを確認する方法はいくつかあります。以下の例では少し大きめの緑色の太文字で入力コマンド部分を示します。方法 1…


ついに解禁!.NET で ZIP 制御

はじめまして。Platform SDK (Windows SDK) サポートの miezure です。 UI や Azure などを担当しています。今回初めてブログを書かせていただくことになりました。みなさまに有益な情報をご案内 できるようがんばります!!どうぞ、よろしくお願いします。 さてさて、3 月も終わりそうな今日この頃ですが、ついに先日 (3/21)、高知市の 桜 が開花したそうです。お花見の季節到来 ですね。毎年桜の開花宣言って誰かがじっと見ていて、咲いたぞー!とかやっているのかな、と疑問に思うところですが、こちら 東京の桜の開花予想は平年より 4 ~ 6 日ほど遅く、4 月 1 日くらいだそうです。しかも 4 月からやっと暖かくなる予想なよう です。桜満開のあたたかい季節到来に、はやくもテンションがあがったところで、本題に突入させていただきます。   ZIP ファイルの制御について 今回のテーマは、ついに解禁! ZIP ファイルの制御 でございます。ご存知のかたも多いとは思いますが、Windows として プログラムから ZIP ファイルを制御する方法はご用意しておりませんでした。 あれ? CopyHere メソッドを使用して制御できるけど。。というかた、さすがです。確かにエクスプローラーが Shell の API を 利用している関係上、CopyHere メソッドでも ZIP ファイルを扱うことが可能となっています。 ただこれは、意図して提供している機能ではないのです。そのため、CopyHere メソッドによる ZIP の制御で問題が発生した…


IConnectableCredentialProviderCredential の利用

PlatformSDK( Windows SDK) サポートの mitsuruw です。 いよいよ春の気配が近付いてまいりました。春と言えば、東大寺のお水取りですね。この季節、奈良では 「お水取りも終わったし、いよいよ春ですね」 というやりとりをよく耳にしますが、この 「お水取り」 というのは通称で、正しくは東大寺二月堂の修二会 (しゅにえ) のことを指します。 全国の神様が東大寺二月堂に集まった際、若狭の国の遠敷明神 (おにゅうみょうじん) という神様だけが川で魚をとっていたため、集会に遅れてしまいました。そのお詫びに遠敷明神は遠敷川から二月堂にお水を送ることにしたそうで、お水取りはこのエピソードに由来していると言われています。私のまわりには 「お水取り」 という単語は知っている方が多いのですが、このあたりの由来をご存じの方はあまりいないようです。これはつまり 「遅刻してしまったおわびにお水をあげます」 というお話なのですが、いつの時代も時間はとても貴重なものです。プログラムが処理に時間がかかっている間も、あまり長く放置されると、待っているユーザーはだんだんイライラしてきてしまいます。こういう時は 「いまがんばっているのでもう少しまってください」 というメッセージを出すだけでも随分印象が違うことでしょう。 そこで今回は、もし Credential Provider で時間のかかる処理を行わなければならない場合に、ユーザーにその旨を伝えるような便利なインターフェスをご紹介したいと思います。 IConnectableCredentialProviderCredential インターフェース Credential Provider を開発したことのある方でも、このインターフェースを使用したことがある方は案外少ないようです。このインターフェースは名前が長いので、ここでは ICCPC と省略させてください。Credential Provider でサブミット ボタン (→ のボタンです) を押下した後で時間がかかるような処理を行う場合には、ICCPC を実装し、Connect() メソッド内でその処理を行う方法が用意されています。このインターフェイスは、本来 VPN などのネットワーク認証を必要とする PLAP (Pre Logon Access Provider) 向けに用意されたものですが、GetSerialization() での認証処理に時間がかかるような場合にも利用することが可能です。 Credential Provider で ICCPC を実装した場合、サブミット ボタン押下時のシーケンスは以下のようになります。   < ICCPC 実装時の処理シーケンス >  1. サブミット…


暗号化 API(Cryptography API) のよくある問題、勘違い!?

こんにちは小泉です。雪は降るし、まだ風も冷たいし、なかなか春の音が聞こえてきませんね。ちょっと寒くて乗らなかったら、そろそろ私のバイクもバッテリの電圧が少なくなってきたようです。たま~に土日に乗ろうとすると、エンジンのかかりが悪く、始動のたびにキュルキュルとご近所迷惑な音を立てる始末。。。。。ご近所のみなさま申し訳ありません。あの音は私です。 さて、今までは私は Network Monitor 、TcpAnalyzer、WinSock API といったネットワーク関連の投稿ばかりでしたが、今回は趣向を変えて暗号化 API に関するお話をさせていただきます。ネットワーク上に流れるデータや、ローカルに保存したデータを安全に取り扱いたいと思ったとき、まず思い浮かぶのはデータの暗号化ではないでしょうか。そんな時に弊社が長年提供している暗号化 API である Cryptography API をご利用されている方も多いかと思います。サポートをしていると、かなりの割合で、初期化関数である CryptAcquireContext API の利用方法に起因したトラブルが多いように感じます。そこで今回は、CryptAcquireContext API をご利用いただく上で、よくある誤解について記載させていただきますね。Cryptography API 初心者の方は今後の開発の際の参考に、経験者の方はトラブルシューティングの際の参考にしていただけますと幸いです。 誤解その 1.—————————————————————————————————————–CRYPT_NEWKEYSET フラグは絶対必要ですか? 回答:共通鍵暗号 (3DES、AES、RC5 等)やハッシユ(SHA1, SHA2)を用いる場合は、必要はありません。CryptAcquireContext API を利用するときに、よく見るのが以下のような呼び出しです。                 // Attempt to acquire a handle to the default key container.                if(!CryptAcquireContext(&hProv, “Test Container”, NULL, PROV_RSA_FULL, 0))                {                                if(GetLastError() != NTE_BAD_KEYSET) {                                                 //…


Windows サービスあれこれ (3) – [スタートアップの種類] を変更してみましょう!

こんにちは、Platform SDK (Windows SDK) サポートの tomoshi です。早いもので 2 月も半ばとなりましたね。そろそろスギ花粉が猛威をふるう季節となりますが、皆様いかがお過ごしでしょうか。実は先日から、スギ花粉のせいなのかどうか、すこぶる目と瞼の調子が良くありません。眼科の診察を受けましたら「瞼に炎症が起きていますね」とのことで、ここ数日はずっと眼鏡で過ごしています。普段はコンタクト レンズを使用していますので、一日中眼鏡で過ごすというのはなかなか新鮮な感じです!これに乗じて、眼鏡を新しく作ろうかな・・・と画策しているところです。   さて今回も、simple サービス サンプルの「知っ得★」なカスタマイズ方法をご紹介していきます。既に皆様にもお馴染みのサンプルとなりましたでしょうか、Windows SDK から提供されている simple サービス サンプルをベースに、「あれこれ」ご紹介させていたければと思います。 なお、simple サービス サンプルの入手方法・ビルド方法は、「Windows サービスあれこれ (1)」でご紹介しておりますので、是非ご確認くださいね。   前回の「あれこれ」では、”Simple Service” サービスのプロパティの中から、[全般] タブの [サービス名] と [表示名] を変更する「知っ得★」をご紹介しました。今回は、同じく [全般] タブの中から [スタートアップの種類] を変更する「知っ得★」をご案内いたします。 先ずはじめに、”Simple Service” サービスのプロパティを確認していきましょう。simple サービス サンプルをインストールすると、コントロール パネルの [管理ツール] – [サービス] から ”Simple Servier” サービスを選択して、各種プロパティを参照することが可能です。     このプロパティ ダイアログ上から手動で変更可能な [スタートアップの種類]…


修正プログラムにまつわるお話

おはようございます。Platform SDK (Windows SDK) サポートの junyoshi です。今年から本ブログのライターとして加わりました。ユーザー インターフェイスやネットワーク、サービスなど、Windows 上でのさまざまなアプリケーション開発について、開発者のみなさんからのお問い合わせに対応しています。以後、お見知りおきいただけますようお願いします。 さて、まったく話は変わりますが、インフルエンザが流行っていますね。今年は A 型が、というお話をよく聞きますが、B 型にかかったという方もいらっしゃるようで、毎年のことながらどれに気を付けたらよいというのはなさそうです。当然、私は医療の専門ではありませんが、先日テレビで「手洗い、うがいは確実なものではない」と放送していました。インフルエンザは飛沫感染で、ウィルスは肌や粘膜に付着したら手洗いやうがいをするよりも早く侵入してしまうから、というのが理由でしたが、そうすると事前に準備が必要なので、予防接種しかないということですね。とは言っても、少しでも遠ざけられるなら、と考えて手洗い、うがいを続けたいと思います。 GDR と LDR って何? Windows をお使いいただいていると、よく Windows Update や Microsoft Update というウィンドウが表示されて Windows を更新するよう促されることがあると思います。OS の不具合が修正されたり、新しいモジュールが提供されたりすると、よりよい環境をご利用いただくためにプログラムが提供されます。PC からインターネットを通じて定期的にマイクロソフトのサイトをご確認いただくことで、新しいモジュールが見つかり、簡単なユーザー インターフェイスによってインストールすることが可能となっています。 でも、実際に Windows Update から PC にインストール可能なプログラムは、マイクロソフトが提供しているものの一部です。たとえ、製品の不具合を修正したものであっても、すべてがインストールされるわけではありません。それはなぜか。 マイクロソフトでは、大きく分けて以下の 2 種類の修正プログラムを提供しています。修正プログラムとは、製品の不具合を修正するプログラムのことです。 Limited Distribution Release (LDR) 以前は、Quick Fix Engineering、略して QFE と呼ばれていました。ある特定の問題を解決するために修正が行われ、その問題が解決されていることをテストにより確認した上で公開された修正プログラムです。局所的なテストとなることが多いので、修正がほかの機能に影響している可能性があります。 General Distribution Release (GDR) 広範囲のお客様に提供するために、さらに多くのプロセスを経て、追加テストなども行った上でリリースされる修正プログラムを指します。 LDR は、局所的な問題解決であり、万人向けとは言い難いため、修正される原因となった問題の影響を受けているお客様向けに提供しています。問題に関する情報は、マイクロソフトの…