2012年12月21日金曜日

タスク イメージ破損、特定用ソフトのご紹介

「タスク イメージは破損しているか、または変更されています
 (HRESULTからの例外:0x80041321) 」
 

破損タスクを探すソフトを開発致しました。

FindBrokenTasks
http://code.google.com/p/kumpro/downloads/list?can=2&q=FindBrokenTasks

Subversionのレポジトリにて、ソースコードも提供しています:
https://kumpro.googlecode.com/svn/trunk/FindBrokenTasks

セットアップを完了し、起動します。問題有りの場合は次のような画面に:


「例外情報」 開発者視点のエラーメッセージを表示致します。
「デスクトップへ複製する」 問題のタスクファイルをデスクトップへ複製します。
「デスクトップへ移動する」 問題のタスクファイルをデスクトップへ移動します。

問題なしの場合は、次のようになります。

2012年12月15日土曜日

Mail.MSMessageStore 解析資料

Mail.MSMessageStore の仕様を独自に解析してみました。

解析資料

データベースには ESE (Extensible Storage Engine) が採用されています。ISAM 形式です。
Outlook Express のデータベースのような 2GB 境界で壊れやすい仕様・実装ではなく、かなり信頼性の高いコンポーネントです。

ESE データベースを閲覧・編集する良い塩梅のソフトがなかなか見つからなくて、作りました。eseViewer です。


Mail.MSMessageStore テーブル一覧:
  • DirtyQueue
  • Folders
  • Junk
  • Messages
  • Offline
  • SearchFolder
  • ServerOperation
  • Streams
  • Uidl
  • UserDataTable

Foldersの中身例:

Messagesの中身例:

2012年12月5日水曜日

Apache OpenOfficeビルド: libxsltでlibxml/xmlversion.hが見つからない

Apache OpenOffice 3.4.1のビルド中に遭遇したエラーです。

=============
Building module libxslt
=============

Entering /home/KU/8/aoo-3.4.1/main/libxslt


Microsoft(R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl.exe /nologo /D "WIN32" /D "_WINDOWS" /D "_MBCS" /W3 /MD /D "_REENTRANT" /I.. /I..\libxslt /I.\include /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /D "NDEBUG" /O2 /Foint.xslt.msvc\ /c ..\libxslt\attributes.c ..\libxslt\documents.c ..\libxslt\extensions.c ..\libxslt\extra.c ..\libxslt\functions.c ..\libxslt\imports.c ..\libxslt\keys.c ..\libxslt\namespaces.c ..\libxslt\numbers.c ..\libxslt\pattern.c ..\libxslt\preproc.c ..\libxslt\security.c ..\libxslt\templates.c ..\libxslt\transform.c ..\libxslt\variables.c ..\libxslt\xslt.c ..\libxslt\xsltlocale.c ..\libxslt\xsltutils.c ..\libxslt\attrvt.c
attributes.c
..\libxslt\win32config.h(92) : fatal error C1083: include ファイルを開けません。'libxml/xmlversion.h': No such file or directory
documents.c
..\libxslt\win32config.h(92) : fatal error C1083: include ファイルを開けません。'libxml/xmlversion.h': No such file or directory
extensions.c
..\libxslt\win32config.h(92) : fatal error C1083: include ファイルを開けません。'libxml/xmlversion.h': No such file or directory

簡単な直し方がわからなかったので、libxslt\makefile.mkを編集しました。

CONFIGURE_DIR=win32
CONFIGURE_ACTION=cscript configure.js
#CONFIGURE_FLAGS=iconv=no sax1=yes
CONFIGURE_FLAGS=include=../../../../../../libxml2/wntmsci12.pro/inc lib=../../../../../../libxml2/wntmsci12.pro/lib

一番下のCONFIGURE_FLAGSを足しました。

更に、libxslt\wntmsci12.pro\misc\build\so_configured_so_libxsltを削除して、configure.jsを再実行できるようにします。

これでビルドしたら成功しました。

美しくない解決法ですが、取り敢えず直りました。しかし、きれいな直し方がわからないのが残念です。

Apache OpenOffice: embedservでatls.libを取り込みしない件

Apache OpenOfficeのビルドで、
ATL_LIBやATL_INCLUDEを正しく設定しているにも関わりませず、
次の様なビルドエラーになる場合が有ります。

Making:    emser.dll
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/MAP /OPT:NOREF -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -RELEASE -DEBUG -INCREMENTAL:NO /SUBSYSTEM:CONSOLE /DLL -out:../wntmsci12.pro/bin/emser.dll -map:../wntmsci12.pro/misc/emser.map -def:../wntmsci12.pro/misc/emser.def -implib:../wntmsci12.pro/lib/emserimp.lib ../wntmsci12.pro/slo/emser_version.obj ../wntmsci12.pro/slo/register.obj ../wntmsci12.pro/slo/servprov.obj ../wntmsci12.pro/slo/docholder.obj ../wntmsci12.pro/slo/ed_ipersiststr.obj ../wntmsci12.pro/slo/ed_idataobj.obj ../wntmsci12.pro/slo/ed_ioleobject.obj ../wntmsci12.pro/slo/ed_iinplace.obj ../wntmsci12.pro/slo/iipaobj.obj ../wntmsci12.pro/slo/guid.obj ../wntmsci12.pro/slo/esdll.obj ../wntmsci12.pro/slo/intercept.obj ../wntmsci12.pro/slo/syswinwrapper.obj ../wntmsci12.pro/slo/tracker.obj isal.lib icppu.lib icppuhelper.lib ole32.lib gdi32.lib uuid.lib oleaut32.lib msvcrt.lib uwinapi.lib kernel32.lib user32.lib oldnames.lib stlport_vc71.lib ../wntmsci12.pro/misc/emser.res
   ライブラリ ../wntmsci12.pro/lib/emserimp.lib とオブジェクト ../wntmsci12.pro/lib/emserimp.exp を作成中
esdll.obj : error LNK2019: 未解決の外部シンボル "class ATL::CAtlComModule ATL::_AtlComModule" (?_AtlComModule@ATL@@3VCAtlComModule@1@A) が関数 "public: long __thiscall ATL::CComModule::Init(struct ATL::_ATL_OBJMAP_ENTRY30 *,struct HINSTANCE__ *,struct _GUID const *)" (?Init@CComModule@ATL@@QAEJPAU_ATL_OBJMAP_ENTRY30@2@PAUHINSTANCE__@@PBU_GUID@@@Z) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル "unsigned int (__stdcall* ATL::g_pfnGetThreadACP)(void)" (?g_pfnGetThreadACP@ATL@@3P6GIXZA) が関数 "unsigned int __stdcall ATL::_AtlGetConversionACP(void)" (?_AtlGetConversionACP@ATL@@YGIXZ) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル __imp__RegDeleteKeyA@8 が関数 "public: long __thiscall ATL::CRegKey::DeleteSubKey(char const *)" (?DeleteSubKey@CRegKey@ATL@@QAEJPBD@Z) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル __imp__RegDeleteValueA@8 が関数 "public: long __thiscall ATL::CRegKey::DeleteValue(char const *)" (?DeleteValue@CRegKey@ATL@@QAEJPBD@Z) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル __imp__RegCloseKey@4 が関数 "public: long __thiscall ATL::CRegKey::Close(void)" (?Close@CRegKey@ATL@@QAEJXZ) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル __imp__RegCreateKeyExA@36 が関数 "public: long __thiscall ATL::CRegKey::Create(struct HKEY__ *,char const *,char *,unsigned long,unsigned long,struct _SECURITY_ATTRIBUTES *,unsigned long *)" (?Create@CRegKey@ATL@@QAEJPAUHKEY__@@PBDPADKKPAU_SECURITY_ATTRIBUTES@@PAK@Z) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル __imp__RegOpenKeyExA@20 が関数 "public: long __thiscall ATL::CRegKey::Open(struct HKEY__ *,char const *,unsigned long)" (?Open@CRegKey@ATL@@QAEJPAUHKEY__@@PBDK@Z) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル __imp__RegSetValueExA@24 が関数 "public: long __thiscall ATL::CRegKey::SetDWORDValue(char const *,unsigned long)" (?SetDWORDValue@CRegKey@ATL@@QAEJPBDK@Z) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル __imp__RegQueryInfoKeyA@48 が関数 "protected: int __thiscall ATL::CRegParser::HasSubKeys(struct HKEY__ *)" (?HasSubKeys@CRegParser@ATL@@IAEHPAUHKEY__@@@Z) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル __imp__RegEnumKeyExA@32 が関数 "public: long __thiscall ATL::CRegKey::RecurseDeleteKey(char const *)" (?RecurseDeleteKey@CRegKey@ATL@@QAEJPBD@Z) で参照されました。
esdll.obj : error LNK2019: 未解決の外部シンボル "class ATL::CAtlBaseModule ATL::_AtlBaseModule" (?_AtlBaseModule@ATL@@3VCAtlBaseModule@1@A) が関数 "public: long __stdcall ATL::CAtlModule::UpdateRegistryFromResourceS(char const *,int,struct ATL::_ATL_REGMAP_ENTRY *)" (?UpdateRegistryFromResourceS@CAtlModule@ATL@@QAGJPBDHPAU_ATL_REGMAP_ENTRY@2@@Z) で参照されました。
../wntmsci12.pro/bin/emser.dll : fatal error LNK1120: 外部参照 11 が未解決です。
dmake:  Error code 96, while making '../wntmsci12.pro/bin/emser.dll'

1 module(s):
        embedserv
need(s) to be rebuilt

WINDOWS_VISTA_PSDKを定義し、適当な値を設定しましょう。

winenv.set.shファイルの中程に行を追加します。

WINDOWS_VISTA_PSDK=aaa

export WINDOWS_VISTA_PSDK=aaa

winenv.set.shの中に入れてもunsetされることが分かりました。都度、環境変数を作りましょう。

さて、atls.libを含まない事がビルドエラーの原因と考えられます。

embedserv\util\makefile.mkを確認しますと、WINDOWS_VISTA_PSDKの内容有無で判断するようになっています。

.IF "$(WINDOWS_VISTA_PSDK)"!=""
SHL1STDLIBS+=\
  $(ADVAPI32LIB) \
  $(ATL_LIB)$/atls.lib
.ENDIF # "$(WINDOWS_VISTA_PSDK)"!=""

C:/cygwinc:/cygwinの件

Apache OpenOffice/LibreOfficeのビルドエラーで、
C:/Cygwinc:/cygwinの文言が出現する場合が有ります。

[ build RES ]
awk: fatal: can't open source file `C:/cygwinc:/cygwin/home/KU/8/aoo-3.4.1/main/solenv/gbuild/processdeps.awk' for reading (No such file or directory)
C:/cygwin/home/KU/8/aoo-3.4.1/main/solenv/gbuild/WinResTarget.mk:59: recipe for target `/home/KU/8/aoo-3.4.1/main/solver/341/wntmsci11.pro/workdir/WinResTarget/comphelper/default.res' failed
make: *** [/home/KU/8/aoo-3.4.1/main/solver/341/wntmsci11.pro/workdir/WinResTarget/comphelper/default.res] Error 2
dmake:  Error code 2, while making 'all'

LINK : fatal error LNK1181: 入力ファイル 'isal.lib' を開けません。

Apache OpenOfficeの場合、winenv.set.shを編集します。
LibreOfficeの場合、Env.Host.shを編集します。

C:/cygwinc:/cygwinに置き換えます。最初のCを小文字のcにします。

C:\\cygwinc:\\cygwinに置き換えます。これも同様です。

書き換えた後、sourceを再実行する事をお忘れなく!

source winenv.Set.sh

これだけでビルドがすっきり通るようになると思います。

2012年11月26日月曜日

IThumbnailProvider+IInitializeWithStream+Windows 8

IThumbnailProvider+IInitializeWithStream+Windows 8で、IStream::Statを実施しても、ファイル名が取得できなくなっています。Windows 7では取得できたのに… 急遽IInitializeWithItemを実装しまして、psi->GetDisplayName(SIGDN_FILESYSPATH, &pszName)で、ファイルパスを取得し、IInitializeWithFile::Initializeに接続し、何とか凌ぎました。

2012年11月14日水曜日

ERROR [HYC00] UTF-8 conversion isn't implemented before 7.1

PostgreSQL 7.0.4 (Linux)から、 PostgreSQL 8.2.22 (Windows)に、移行する依頼を受けています。 pg_dumpを使うと、文字化けが起こります。 Npgsqlを使うと、Connection.Openで、固まります。 Odbcを使うと、"ERROR [HYC00] UTF-8 conversion isn't implemented before 7.1"が発生します。 対策を探しています。

2012年9月20日木曜日

Copy2Glacier仕様 (SlowGlacier)

Copy2Glacierとは、Amazon Glacierに「ゆっくりと」ファイルをアップロードするプログラムです。

入手につきましては、準備中です。

開発の動機としまして:
  • ノートパソコンのディスクイメージを複数持っていて、保管したい。安全に! 長期で!
  • 30GB/日制限が有り、全速力でアップロードすると制限に触れて問題が発生します。
さて、これよりCopy2Glacierの使い方・どのように動作するのか・作りこみをざっくりと紹介していきます。

使い方

C:\GLACIER>Copy2Glacier.exe
Copy2Glacier /ia1 <access key>
Copy2Glacier /ia2 <secret key>
Copy2Glacier /partsize <part size. default: 4194304>
Copy2Glacier /region <region system name. default: us-east-1>
Copy2Glacier /prep <up info file> <file> <vault name>
Copy2Glacier /up <up info file> <max parts count to upload>

prepの使い方


元のファイルを読み取って、アップ情報ファイルを作成します。

C:\GLACIER>Copy2Glacier.exe /prep PC2 2010-04-09-13-img-pc2-recovery.7z 2010-04-09-13-img-pc2-recovery.7z
ハッシュ計算するので、少し時間が掛かります。

作成したアップ情報ファイルは、大体次のようなります。ANSIエンコード(CR LF)で保存します。日本語WindowsであればCP932。*n?xであれば、EUC/UTF8等、環境による。最初はUnicodeと書いていたのですが、途中で書き直してややこしい事に。(^^;

#!Copy2Glacier
C:\GLACIER\2010-04-09-13-img-pc2-recovery.7z
:archivesize 9033470095
:partsize 4194304
:vaultname 2010-04-09-13-img-pc2-recovery.7z
+ 0 4194304 8e08b908dbe67e8c20a8859407d656df7b73d3989217c8943c0c654c618cfabe
+ 4194304 4194304 d4f270466bc4c79dd4393d12aa06aea4a087d2ea9aad2ca099c3ac85c67bd9d9
+ 8388608 4194304 0c36970933853ce5844cf94c2dd7d5cbc2c7c40c6180f6ac7637cb0aef915874
...
+ 9026142208 4194304 52dc52bf516d11fd649e6d334eb1cd9cfc884cedf207ead58e6b77f9fd3d0887
+ 9030336512 3133583 d2aedbaf9a03f34227384aa18c4a072b2d975a19ac3856da938e411aaaf88a5a
$ 8a0e3deb40a6caa8da0755c5c945ce9e4e3af57c27fd65e236c11c7f4f425176
1行目は、ファイル形式用のマジック
2行目は、元のファイルのフルパス。
3行目(:archivesize)は、ファイルのバイト数(Int64)
4行目(:partsize)は、断片の大きさ・バイト数
5行目(:vaultname)は、保管庫の名前
コロンで始まる行は、KeyとValueをペアにした設定値です。
プラスで始まる行は、UploadMultipartPartRequestに使用する情報です。(断片の開始オフセット バイト数 ハッシュ値)で構成されます。
ダラーで始まる行は、ツリーハッシュを示します。

いずれもAmazon Glacierにアップロードする際に必要となる情報です。

up


次に、アップロードのコマンドです。4MBの断片を10個上げる指示をしています。これをジョブ化しておけば、ゆっくりアップロードを実現できます:

C:\GLACIER>Copy2Glacier.exe /up PC2 10
アップロードが進みますと、アップ情報ファイルに追記していきます。

:location /XXXXXXXXXXXX/vaults/2010-04-09-13-img-pc2-recovery.7z
:uplocation /XXXXXXXXXXXX/vaults/2010-04-09-13-img-pc2-recovery.7z/multipart-uploads/XXXX-XXXXXXXXXXXXXXXGFF8yd18rTKveS8BbF5IH8MbBKm8Ff-XXXXXXXXXX_XXXXXXXXXXXXXXXXXXXXXX3l0J7T2s
:uploadid XXXX-XXXXXXXXXXXXXXXXXX8yd18rTKveS8BbF5IH8MbBKm8Ff-XXXXXXXXXt_eXXXXXXXXXXXXXXXXBA3XXXXXX7T2s
- 0 4194304 8e08b908dbe67e8c20a8859407d656df7b73d3989217c8943c0c654c618cfabe
- 4194304 4194304 d4f270466bc4c79dd4393d12aa06aea4a087d2ea9aad2ca099c3ac85c67bd9d9
- 8388608 4194304 0c36970933853ce5844cf94c2dd7d5cbc2c7c40c6180f6ac7637cb0aef915874
- 12582912 4194304 87a129960848bc6e279721d191484d13127466e7a05faab3d347ff80198b83ee
- 16777216 4194304 34bf57c6b63e49ec30aec18b02d03326250fbaf5b5abf74a460816c9ef4362ca
身の安全が為、一部を伏字にしています。

:locationは、CreateVaultRequestの結果、返ってきますLocationの内容を格納します。
:uplocationは、InitiateMultipartUploadの結果、返ってきますLocationを格納、
:uploadidは、同UploadIdを格納します。

3つのうち、必要なのはuploadidだけで、他は無くてもアップロードを完遂できます。

ハイフンで始まる行は、UploadMultipartPartが済んでいますよ、という情報です。プラスの時と同じく(断片の開始オフセット バイト数 ハッシュ値)で構成されます。

こうしておけば、二度目・三度目の実行で、どこから続きをやれば良いか、容易にわかります。

また、多重実行できないように、ファイルを排他オープンにします。「ゆっくり」アップロードする都合上、2個以上のプロセスで実行する必要がないので。

さて、アップロードが最後まで完了しますと、archiveidを発行します。

:archiveid XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXQNqcmFB3ta-XXXXXXXXXXXXXXXK9Td9_XXXXXXXXIGsbGggMs6Qtsr_XXXXXXXXXXZEU-XXXXXXXXXXXXXXXXXXXXXXXXXXXpU7-XXXX

こうしておけば、アップロードが完了した後に、もう一度上げなおす、という問題を防ぐことができます。

このarchiveidは大変重要で、後でダウンロードしたり、削除する時に必要です。

紛失しても取得はできるのですが、何時間も掛かってしまう、という情報がネットに散見されます。

こういう感じで、ディスクイメージを保管しようと頑張っています。

後日談有りましたら、情報発信して行こうと思います。

2012年8月30日木曜日

Malformed permissions property: 'langid' 対策

(臨時修正版:https://drive.google.com/open?id=1C6mmykeZD4LCpTzvEp272PDgOwrE_c0B

Windows 8又はWindows Server 2012に、PostgreSQL 8.2 の導入を試みると、失敗するようです。

次の様なエラーメッセージが表示されます。

Malformed permissions property: 'langid'

原因を特定致しました。

未初期化の変数に対する読み取りアクセスが原因のようです。(これは、PostgreSQL側に問題が有ります。Windows側の問題では有りません。)

修正ファイル編:

mstファイル置き場へのリンクを設置致します。使用方法につきましては、各人にて調査され、対処してください。自己責任でお願いいたします:
https://sites.google.com/site/kaihatsublog/pginstca

分析編:

次にコードを示します。(pgFoundary/pginstaller/pginst/ca/pginstca.cファイル中、RunInitdbから抜粋しています)

 serverdir = strchr(langid,';');
 if (!datadir)
 {
  SendErrorMessage(hInstall,L"Malformed permissions property: 'langid'.");
  return ERROR_INSTALL_FAILURE;
 }

serverdirに書き込んでいるのに、datadirを読み取っています。

Windows 8以前では、未使用のスタックが汚れていた(?)ため、発現しなかったようですが、
Windows 8以遠では、未使用のスタックを0で掃除する(?)ようになったため、発現するようです。

この問題は8.2以降で修正されていますが、8.2系列には補修が適用されていないようです。

Orca及びOllyDbg v2.01 (beta 2)の力を借り、解析しました所、次の様になっています。


そこでパッチを当てました。pginstca 3758 EC F0

Stirlingでパッチを適用し、Orcaで書き戻した所、セットアップが成功するようになりました。

2012年8月24日金曜日

IIS6で、CGIアプリが致命的なエラーになった場合

SetErrorMode

私のWindows 7パソコンにて実行した場合: 0

  • 0
  • システム既定の処理を行い、どの場合でもエラーダイアログボックスを表示します。

IIS6のCGIにて実行した場合: 32769

  • 1
  • SEM_FAILCRITICALERRORS
  • システムは、致命的なエラーに関するメッセージボックスを表示せず、呼び出し側プロセスへそのエラーを送信します。

  • 32768
  • SEM_NOOPENFILEERRORBOX
  • システムは、ファイルが見つからなかった場合にメッセージボックスを表示せず、呼び出し側プロセスへそのエラーを返します。


SetErrorModeの初期値が異なる、という事でございますが…

SEM_FAILCRITICALERRORSの件の

呼び出し側プロセスへそのエラーを送信しますって怖くないでしょうか?

子プロセスで0xC0000005(アクセス違反)が発生したら、
親プロセスも0xC0000005(アクセス違反)で、強制終了を喰らうという事でしょうか??



次の様なこういう構成なのですが、

親プロセス=CMD.exe
子プロセス=COM/OLEを使って実現している、サムネイル生成用の物

親プロセスまで0xC0000005が伝播している事例を、今までに見たことがあるような、そんな気がしています。

2012年7月17日火曜日

pdftotextで起こる怪

pdftotextで、PDFファイルからテキスト抽出しますと、怪しい表現になる場合が有ります。

「ソフトウェア」が、「ソフトウェゕ」に化けてしまう。「ソフトウェゕ」で、検索

「ユーティリティ」が、「ユーテゖリテゖ」が化けてしまう。「ユーテゖリテゖ」で、検索

ご存知ないでしょうか…

2012年7月12日木曜日

WinDbgで、エラー報告データを解析2(.NETfx 2.0向け)

前回の続編です。

今回は、スタックトレースを見ながら要因を追跡していきます。

WinDbgを起動します。

[File]→[Open Crash Dump...]

次の場所を開く(Windows Server 2003):
%USERPROFILE%\Local Settings\Application Data\PCHealth\ErrorRep\QSignoff

8C80969E.cab等、cabを開きます。

~~~

打ち込みます(.NET Framework 2.0対応のため)

.load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll

結果:
0:002> .load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll

------------------------------------------------------------ 
sos.dll needs a full memory dump for complete functionality. 
You can create one with .dump /ma <filename>
------------------------------------------------------------ 

~~~

打ち込みます。発出された例外を表示。

!pe

結果:
0:002> !pe
Exception object: 09fb423c
Exception type: System.IO.IOException
Message: 指定されたネットワーク名は利用できません。
InnerException: <none>
StackTrace (generated):

SP       IP       Function
00A4FB64 799D0B09 mscorlib_ni!System.IO.__Error.WinIOError(Int32, System.String)+0x75c9f9
00A4FBC0 79A0CE90 mscorlib_ni!System.IO.FileStream.WriteCore(Byte[], Int32, Int32)+0x7221a0
00A4FBE0 792EACD2 mscorlib_ni!System.IO.FileStream.FlushWrite(Boolean)+0x22
00A4FBF0 792EB7F7 mscorlib_ni!System.IO.FileStream.Dispose(Boolean)+0x57
00A4FC20 792CA80B mscorlib_ni!System.IO.FileStream.Finalize()+0x1b

StackTraceString: <none>
HResult: 80070040

考察:
  • FileStreamがExceptionの発生源になっています。
  • FileStreamは、ファイル名を持っているはずなので、それを探ってみたいと思います。

~~~

打ち込みます(スタックトレースを表示します)

!CLRStack -p

結果:

0:002> !CLRStack -p
OS Thread Id: 0x2198 (2)
ESP       EIP 
00a4fac0 7c97845c [HelperMethodFrame: 00a4fac0] 
00a4fb64 799d0b09 System.IO.__Error.WinIOError(Int32, System.String)
  PARAMETERS:
   errorCode = <no data>
   maybeFullPath = <no data>

00a4fbc0 79a0ce90 System.IO.FileStream.WriteCore(Byte[], Int32, Int32)
  PARAMETERS:
   this = <no data>
   buffer = <no data>
   offset = <no data>
   count = <no data>

00a4fbe0 792eacd2 System.IO.FileStream.FlushWrite(Boolean)
  PARAMETERS:
   this = 0x010a3550
   calledFromFinalizer = <no data>

00a4fbf0 792eb7f7 System.IO.FileStream.Dispose(Boolean)
  PARAMETERS:
   this = 0x010a3550
   disposing = 0x00000000

00a4fc20 792ca80b System.IO.FileStream.Finalize()
  PARAMETERS:
   this = <no data>

考察:
  • FileStreamのthisポインタが露出しています。
  • FileStreamのthisポインタから、インスタンスの内容物を解剖します。
~~~

打ち込みます。FileStreamのthisポインタをダンプします。

!do 0x010a3550

結果:
0:002> !do 0x010a3550
Name: System.IO.FileStream
MethodTable: 793051f4
EEClass: 790df0f0
Size: 80(0x50) bytes
 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
79330888  400018a        4        System.Object  0 instance 00000000 __identity
7992db14  4001b70        8 ...ream+ReadDelegate  0 instance 00000000 _readDelegate
7992dba0  4001b71        c ...eam+WriteDelegate  0 instance 00000000 _writeDelegate
7931c008  4001b72       10 ...ng.AutoResetEvent  0 instance 00000000 _asyncActiveEvent
79332eb8  4001b73       14         System.Int32  1 instance        1 _asyncActiveCount
7932e968  4001b6f      574     System.IO.Stream  0   shared   static Null
    >> Domain:Value  00161ee0:0109bab4 <<
793336dc  4001bfb       28        System.Byte[]  0 instance 010a4a90 _buffer
79330c6c  4001bfc       2c        System.String  0 instance 010a35a0 _fileName
79304738  4001bfd       44       System.Boolean  1 instance        0 _isAsync
79304738  4001bfe       45       System.Boolean  1 instance        0 _canRead
79304738  4001bff       46       System.Boolean  1 instance        1 _canWrite
79304738  4001c00       47       System.Boolean  1 instance        1 _canSeek
79304738  4001c01       48       System.Boolean  1 instance        0 _exposedHandle
79304738  4001c02       49       System.Boolean  1 instance        0 _isPipe
79332eb8  4001c03       34         System.Int32  1 instance        0 _readPos
79332eb8  4001c04       38         System.Int32  1 instance        0 _readLen
79332eb8  4001c05       3c         System.Int32  1 instance     4096 _writePos
79332eb8  4001c06       40         System.Int32  1 instance     4096 _bufferSize
7932ec38  4001c07       30 ...es.SafeFileHandle  0 instance 010a3640 _handle
793324f8  4001c08       18         System.Int64  1 instance 111877 _pos
793324f8  4001c09       20         System.Int64  1 instance -1 _appendStart
79304738  4001bf9      adc       System.Boolean  1   shared   static _canUseAsync
    >> Domain:Value  00161ee0:1 <<
79334198  4001bfa      57c ...ompletionCallback  0   shared   static IOCallback
    >> Domain:Value  00161ee0:0109d148 <<

考察:
  • _fileName が 010a35a0 を指しています。
~~~

打ち込みます。

!do 010a35a0


結果:
0:002> !do 010a35a0 
Name: System.String
MethodTable: 79330c6c
EEClass: 790ed65c
Size: 158(0x9e) bytes
 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: \\192.168.2.119\share\DD7Backup\FDSET\DD7Backup遠方(11日)(夜)(Set1)(遠).log
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
79332eb8  4000096        4         System.Int32  1 instance       71 m_arrayLength
79332eb8  4000097        8         System.Int32  1 instance       70 m_stringLength
7933194c  4000098        c          System.Char  1 instance       5c m_firstChar
79330c6c  4000099       10        System.String  0   shared   static Empty
    >> Domain:Value  00161ee0:01091198 <<
7933189c  400009a       14        System.Char[]  0   shared   static WhitespaceChars
    >> Domain:Value  00161ee0:01091714 <<

考察:
  • 知りたかった情報が露出しました。

「指定されたネットワーク名は利用できません」の発生原因は、
バックアップのログファイルを書き込んでいる最中に、
NASがダウンしたからだ、と考えられます。


※ google-code-prettifyを組み込み、表示を最適化しました。

参考:SOS.dll (SOS デバッガー拡張)

2012年7月5日木曜日

Alphaleonis.Win32.Vss.VssSnapshotSetInProgressException

対策:
  • Volume Shadow Copyサービスを開始状態→停止状態にしました。
考えられる点:
  • 短時間で、スナップショットを作って消して、を繰り返すと発生するようです。

―――

Alphaleonis.Win32.Vss.VssSnapshotSetInProgressException はハンドルされませんでした。
  Message="The creation of a shadow copy is already in progress."
  Source="AlphaVSS.60.x64"
  StackTrace:
       場所 Alphaleonis.Win32.Vss.VssBackupComponents.StartSnapshotSet()
       場所 DiffBkCli.MSSnap.Start() 場所 C:\Proj\SyncAmaz\MSSnap.cs:行 90
       場所 SyncAmaz.Program.Main(String[] args) 場所 C:\Proj\SyncAmaz\Program.cs:行 167

―――

ログの名前:         Application
ソース:           VSS
日付:            2012/07/04 10:30:26
イベント ID:       13
タスクのカテゴリ:      なし
レベル:           エラー
キーワード:         クラシック
ユーザー:          N/A
コンピューター:       DD11
説明:
ボリューム シャドウ コピー サービス情報: CLSID {e579ab5f-1cc4-44b4-bed9-de0991ff0623} および名前 Coordinator を持つ COM サーバーを開始できません。[0x80070005, アクセスが拒否されました。
] 
イベント XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="VSS" />
    <EventID Qualifiers="0">13</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2012-07-04T01:30:26.000000000Z" />
    <EventRecordID>9687</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DD11</Computer>
    <Security />
  </System>
  <EventData>
    <Data>{e579ab5f-1cc4-44b4-bed9-de0991ff0623}</Data>
    <Data>Coordinator</Data>
    <Data>0x80070005, アクセスが拒否されました。
</Data>
    <Data>
    </Data>
    <Binary>2D20436F64653A2041444D50524F434330303030303135302D2043616C6C3A2041444D50524F434330303030303134342D205049443A202030303030323330342D205449443A202030303030343130382D20434D443A202076737361646D696E20206C69737420736861646F777320202D20557365723A204E616D653A20444431315C4B552C205349443A532D312D352D32312D3533323737373434382D323532383834363738392D323437363039333533372D31303031</Binary>
  </EventData>
</Event>
※ google-code-prettifyを組み込み、表示を最適化しました。

2012年6月30日土曜日

LibreOfficeとunoconvを、IIS6で動かした!

この問題の対処法が判りました:
Failed to connect to C:\Program Files\LibreOffice 3.5\program\soffice.exe (pid=10080) in 6 seconds.
Connector : couldn't connect to socket (WSAECONNREFUSED, Connection refused)
Error: Unable to connect or start own listener. Aborting. 
対策:(2012/07/05に大幅修正!)

① IUSRを止めて、一般的なアカウントに変更する。
Users権限を持っていれば十分です。Administrators権限は不要です。


参考:https://github.com/dagwieers/unoconv/issues/44

② AppDataのパスを固定化する。

それでもダメなら、AppDataのパスを固定化します。

その一般的なアカウントでログインし、レジストリエディタを立ち上げます。例:
runas /u:Pro4 /p regedit.exe
レジストリの次の場所のAppData値
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
こちらの指している場所を、具体的なパスに変更する。例:
C:\Documents and Settings\Pro4\Application Data
こんな感じです:

最初は次のようになっています:
%USERPROFILE%\Application Data

原因:(2012/07/05に修正)

長々と追跡しましたが、次の箇所で、失敗していたようです。
if ( !GetSpecialFolder( &ustrFile, CSIDL_APPDATA) )
普通はここで失敗しない手はずですが…

IUSR_XXXのアカウントを確認しますと、Guests権限になっていました。

また、IIS7.5では、IUSRは、NT AUTHORITY\IUSRに収まっていたりと、低権限故のアクセス制限が多数掛けられている可能性が見込まれます。

それで、CSIDL_APPDATAは、bootstrap.ini中の、$SYSUSERCONFIGを解決する際に必要とされます。
UserInstallation=$SYSUSERCONFIG/LibreOffice/3
utl::Bootstrap::locateUserInstallationが、それを取得しようとしますが、GetSpecialFolderで失敗します。
return UserInstall::E_Creation;
UserInstall::UserInstallError instErr_fin = UserInstall::finalize();まで戻りまして、次の様な具合で落ちます:
HandleBootstrapErrors( BE_USERINSTALL_FAILED );
「プログラムは起動できません。」「内部エラーが発生しました。」を表示する事になる様です:
FatalError(aMessage);

2012年6月29日金曜日

LibreOfficeとunoconvを、IIS6で動かしたい

Word/Excel/PowerPoint等の文書データを、PDFに変換しようと試みています。

unoconvを、IIS6+PHP5.4上で動かして、少ない手数で実現したい…

然しながら、うまくいっていません。

unoconvが期待するように動いてくれません:
  • デスクトップ環境では、期待する様に動きます。
  • しかし、IIS6環境では、失敗しています。
Webブラウザでは、次のようなメッセージを受け取っています:
Failed to connect to C:\Program Files\LibreOffice 3.5\program\soffice.exe (pid=10080) in 6 seconds.
Connector : couldn't connect to socket (WSAECONNREFUSED, Connection refused)
Error: Unable to connect or start own listener. Aborting.
unoconvの問題ではなく、LibreOfficeの方がトラブルに巻き込まれている感じです。

解決を図るために、いつもの如く、Google先生に頼み込みます:
同じ境遇の方もいらっしゃるようですが、未だ解決策は見つかっていません。

という訳で、自力調査が始まります。

~~~

途中は省きますが、

LibreOfficeがMessageBoxを表示して、入力を待っていることが分かりました。

デスクトップにはMessageBoxは表示されませんが、裏方で表示されている様です。

次の図は、WinDbgでsoffice.binをアタッチした時の様子です。スタックトレースを追跡し、MessageBoxの引数をメモリダンプで確認しています:

ちょうど、次のようなメッセージボックスを表示して停止しているのでしょう。再現してみました:

次の方策は、自炊のデバッグ版LibreOfficeで以て、エラー箇所を特定することです。ご期待ください!

2012年6月5日火曜日

私製INetCfg

INetCfgを使用して得られる、バインド情報を可視化してくれるプログラムを書いています。


この図を見ていますと、INetCfgの構造が把握し易くなります。

背景としましては:
  • ウィルス対策ソフトに不備が有る! 事が有ります。
  • その不備によって、Windowsが起動する際に、ネットワークアダプタを全部隠してしまう場合が有ります。
  • 仮説としましては、バインド情報を破壊しているのではないか、という事。
  • その際に、現状のバインド情報を可視化し、情報収集に役立てよう、という算段です。

2012年4月24日火曜日

LibreOffice「ActiveX Control to Display Documents in Internet Explorer」の件

或る時のOpenOffice.org Writer/Calcでは、Internet Explorerに文書を表示できていました。

参考になる画面写真:
http://sites.google.com/site/kaihatsublog/activex-control-plugin-viewer/openoffice-org-writer
http://sites.google.com/site/kaihatsublog/activex-control-plugin-viewer/openoffice-org-calc


これが、LibreOfficeになってから、表示できなくなっています。

しかし、ヘルプによりますと、表示できることになっています。

Internet Explorer でドキュメントを表示させるための ActiveX コントロール
http://help.libreoffice.org/Common/ActiveX_Control_to_Display_Documents_in_Internet_Explorer/ja


どういう事か調べましたら、情報が有りました。

Windows build with ActiveX
http://nabble.documentfoundation.org/Windows-build-with-ActiveX-td3926953.html

~~~~~
英文:

I tried to find the activex dll (so_activex.dll & so_activex64.dll) in my  
latest official install (LibreOffice 3.5.2.2 / Version ID :  
281b639-6baa1d3-ef66a77-d866f25-f36d45f) and did not find it.
I did find it in the latest build of
Win-x86@15-Prague_Win32 tinderbox  
though (program subfolder).

Is it intentional we do not provide it by default or not ?

Yes, it is. We disable it in distro-configs/LibreOfficeWin32.conf
(--disable-activex-component). You can enable it in your own build and
play with it. As Tor mentined in the other thread, it does not work as
one can expect
, and it has no maintaner, so in order to avoid numerous
bug reports we simply disable it.


~~~~~
和訳:

私は公式の最新版LibreOffice3.5.2.2から、activex dllを見つけ出そうとしましたが、見付かりませんでした。
Tinderboxの最新ビルドからは、その機能を見つけることができましたが…

その機能の提供有無についての判断は、故意によるものですか?

はい。そうです。我々はdistro/configs/LibreOfficeWin32.conf (--disable-activex-component)で、その機能を無効にしています
あなたは、自分のビルドにおいて、その機能を有効にできます。
Tor氏が他のスレッドで言及しているように、その機能は期待するようには動いておらず手入れできる人材もいません。数え切れない数のバグレポートを回避するために、我々は単にその機能を無効にしています

きちんと事情が有るようでした(^^;

2012年4月21日土曜日

エクスプローラのロックと待機チェーン

Windows Server 2008 R2 Foundationを常用しています。

このOSのリソースモニターに、「待機チェーン」を見る機能が備わっています。(以前のWindowsにも備わっている機能かもしれませんが…)


プログラムがフリーズしている場合に見ると、原因調査の役に立つようです。

普段は全く、見る必要のない画面です。

~~~

「ショートカットキー」を使って、アプリの切り替えをバンバンしていますと、時々フリーズ状態が起こります。

画面写真の内容は、丁度、そのフリーズ状態で、エクスプローラの分析結果を撮ったものです。

「ショートカットキー」とは、どちらの「ショートカットキー」でしょうか。

ショートカットのプロパティを表示しますと、「ショートカットキー」の設定が有ります:


コマンドプロンプトのショートカット・プロパティを表示しています。

同時に4つは使いたいので、4つショートカットを探し出しては、別々のキーを割り当てています。
 
Ctrl+Alt+M 「Visual Studio 2005 コマンド プロンプト」
Ctrl+Alt+N 「SDK コマンド プロンプト」
Ctrl+Alt+. 「Visual Studio Command Prompt (2010)」
Ctrl+Alt+, 「Visual Studio 2008 コマンド プロンプト」

良く分からないのですが、切り替えるタイミングによってフリーズを起こします。

解決方法をご存知ではないでしょうか…

~は動作を停止しました (CLR20r3:MDbg.exe編)

初めての方は、前編をご覧ください。

今回は、
.NET SDK コマンド ライン デバッガ (MDbg.exe) を用いて進めていきます。

.NET Framework 2.0 SDK等、SDKを入れていないと使えません。納品先等で活用したい場合は、持ち運ぶ等の工夫をします。

使用の際の注意点を:

Error: デバッグ対象とデバッガが互換性のないプラットフォームにあるので、操作に失敗しました。 (HRESULT からの例外: 0x80131C30)

32ビット版・64ビット版の区別、つまりPlatformの区別が有ります。

64ビット版(x64)の.NET Frameworkで動いているプログラムにアタッチするには、64ビット版のSDKに含まれているMDbg.exeを使います。

つまり「デバッガのPlatform=アタッチ先のPlatform」となるように、Platformを合わせる必要が有ります。

起動:

C:\Program Files\Microsoft.NET\SDK\v2.0 64bit\Bin>Mdbg.exe

MDbg (Managed debugger) v2.0.50727.42 (RTM.050727-4200) started.
Copyright (C) Microsoft Corporation. All rights reserved.

For information about commands type "help";
to exit program type "quit".

mdbg>

a」コマンドで、アタッチ可能なプロセス一覧を表示します。

mdbg> a
Please choose some process to attach
Active processes on current machine:
(PID: 968) C:\Proj\FNF\bin\Debug\FNF.exe
        (ID: 1) FNF.exe
(PID: 4020) C:\Proj\FNF\bin\Debug\FNF.vshost.exe
        (ID: 1) FNF.vshost.exe


a 968」を、実行。968番にアタッチします。

mdbg> a 968
[p#:0, t#:0] mdbg>


ちょっとプロンプトが変わりました。

p -d」で、デバッガ変数の一覧を表示します。例外落ちで停止しているので、$exが現れています。

[p#:0, t#:0] mdbg> p -d
$ex=System.ComponentModel.Win32Exception
$thread=System.Threading.Thread


p $ex」で、例外情報を見ます。

[p#:0, t#:0] mdbg> p $ex
$ex=System.ComponentModel.Win32Exception
        nativeErrorCode=2
        _className=<null>
        _exceptionMethod=<null>
        _exceptionMethodString=<null>
        _message="指定されたファイルが見つかりません。"
        _data=<null>
        _innerException=<null>
        _helpURL=<null>
        _stackTrace=array [192]
        _stackTraceString=<null>
        _remoteStackTraceString=<null>
        _remoteStackIndex=0
        _dynamicMethods=<null>
        _HResult=-2147467259
        _source=<null>
        _xptrs=0
        _xcode=-532459699


情報が見えてきました。

w」で、スタックトレースを見ます。

[p#:0, t#:0] mdbg> w
Thread [#:0]
*0. System.Diagnostics.Process.StartWithShellExecuteEx (source line information unavailable)
 1. System.Diagnostics.Process.Start (source line information unavailable)
 2. FNF.Program.Run (Program.cs:13)
 3. FNF.Program.Main (Program.cs:9)


Process.Startの中でトラぶっているのが判ります。

これで大体の原因は判ると思います。

それで、今回の例外落ちプログラムのソースコードは次のようになっています:

using System;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;

namespace FNF {
    class Program {
        static void Main(string[] args) {
            new Program().Run();
        }

        private void Run() {
            Process.Start(Guid.NewGuid().ToString("N") + ".exe");
        }
    }
}

~は動作を停止しました (CLR20r3編)

納品先などで、.NET Framework用プログラムが例外落ちした際の、例外情報の取得方法について考えてみたいと思います。

例外落ちの際、次のような画面が表示されると思います。



「問題の詳細」を一見しても、中身が判らないことが多いです:
---
説明:
  Stopped working

問題の署名:
  問題イベント名:                          CLR20r3
  問題の署名 01:                         fnf.exe
  問題の署名 02:                         1.0.0.0
  問題の署名 03:                         4f921d53
  問題の署名 04:                         System
  問題の署名 05:                         2.0.0.0
  問題の署名 06:                         4ea78da2
  問題の署名 07:                         3aae
  問題の署名 08:                         288
  問題の署名 09:                         System.ComponentModel.Win32
  OS バージョン:                          6.1.7601.2.1.0.272.33
  ロケール ID:                             1041

オンラインのプライバシーに関する声明をお読みください:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0411

オンラインのプライバシーに関する声明が利用できない場合は、プライバシーに関する声明をオフラインでお読みください:
  C:\Windows\system32\ja-JP\erofflps.txt
---

「System.Component.Win32Exceptionが発生したのか」程度は読み取ることができます。

イベントビューアで確認しても、似たような情報しか無いので、詳細に行き着きません。

そこで、プログラム終了する前に、デバッガをアタッチし、原因を追究します。

ここからは、デバッガごとに記事を分けたいと思います:

MDbg.exe

2012年4月5日木曜日

netatalk-2.xをCygwinでビルドしますとcat: command not found等を連発する件

Cygwinにて、netatalkのconfigureを実行中、Checking Berkeley DB libraryの辺りから挙動が怪しくなります:

checking Berkeley DB library (-ldb46)...
./configure: line 31862: cat: command not found
./configure: line 31865: cat: command not found
./configure: line 31866: cat: command not found
./configure: line 31889: rm: command not found
./configure: line 31919: sed: command not found


PATHが壊されているものと推測。

追求してみました。次の行で壊れています:

eval export $shlibpath_var=$bdblibdir

このshlibpath_varの出所は:

  dynamic_linker='Win32 ld.exe'
  # FIXME: first we should search . and the directory the executable is in
  shlibpath_var=PATH


ここで壊れる原因を作っているようです。

取り敢えずの回避策につきましては、

aclocal.m4を修正します:

  dynamic_linker='Win32 ld.exe'
  # FIXME: first we should search . and the directory the executable is in
  shlibpath_var=LIBPATH


PATHをLIBPATHに変えただけです。

この後、

autoconf
./configure --with-bdb=/usr/local
make

等でビルドを進めて行きます。

netatalk-3 の場合は、ちょっと下の『shlibpath_varの件は』を参照。

―――

bin/megatron/macbin.cの90行目辺り:

bin.gmtoff = tp->tm_gmtoff;

tm_gmtoffが無い、といわれた場合は、config.hのNO_STRUCT_TM_GMTOFFを定義する必要が有りそうです。

/* Define if the gmtoff member of struct tm is not available */
#define NO_STRUCT_TM_GMTOFF 1

本当は、configure.acを触って、cygwinの場合は、AC_DEFINE(NO_STRUCT_TM_GMTOFF)を加えるのがより良い方法と思いますが、今回はこれで。。。

―――

shlibpath_varの件は、/usr/share/aclocal/libtool.m4を修正した方が根本解決になるかもしれません。:

  # FIXME: first we should search . and the directory the executable is in
  shlibpath_var=LIBPATH


libtool.m4が無い場合は、Cygwinのsetup.exeでlibtoolを入れておきましょう

次に、再構築:

aclocal -I macros
autoconf
./configure --with-bdb=/usr/local
make

―――

NO_STRUCT_TM_GMTOFFの件は、configure.acを修正できます:

1箇所目。前後の文言で探して、太字部分を足す:

dnl --------------------- determine operating system from "target"
case "$host_os" in
...

 *cygwin*)   this_os=cygwin ;;esac

2箇所目。前後の文言で探して、太字部分を足す:

dnl ----- Cygwin specific -----
if test x"$this_os" = "xcygwin"; then
 AC_MSG_RESULT([ * CYGWIN specific configuration])
 AC_DEFINE(NO_STRUCT_TM_GMTOFF, 1, [Define if the gmtoff member of struct tm is not available])
fi

dnl ------ Check for sendfile() --------
次に、再構築:

autoconf
./configure --with-bdb=/usr/local
make

―――

checking whether to enable srvloc (SLP) support... no
./configure: line 15955: syntax error near unexpected token
`AVAHI,'

macros/zeroconf.m4で、PKG_CHECK_MODULESが解決できないために出ている様です。

Cygwinのsetup.exeで、pkg-configを入れましょう。

―――

/bin/sh ../../libtool --tag=CC    --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..      -I../../include -D_U_="__attribute__((unused))" -g -O2 -I../../sys -MT cache.lo -MD -MP -MF .deps/cache.Tpo -c -o cache.lo cache.c
../../libtool: line 879: X--tag=CC: command not found
../../libtool: line 912: libtool: ignoring unknown tag : command not found
../../libtool: line 879: X--mode=compile: command not found


netatalk付属のlibtoolの挙動が怪しかったら、/bin/libtoolから持って来ましょう。
―――

2012年4月2日月曜日

2012年3月28日水曜日

jpegをWindowsでビルド

makefile.vcを修正:
CFLAGS= $(cflags) $(cdebug) $(cvarsdll) -I.

nmake -f makefile.vc nodebug=1

freetypeをWindowsでビルド

特定のmingw32-make.exeを用意します。

http://sourceforge.net/projects/mingw/files/MinGW/Extension/make/mingw32-make-3.81-20090910/
mingw32-make-3.81-20090910.tar.gzを使用します。

\msys\1.0などに展開。
builds\compiler\visualc.mkを編集。MS VC Runtime Libraryをダイナミックリンクするように指定。
CFLAGS ?= /nologo /c /Ox /W3 /MD

\msys\1.0\bin\mingw32-make.exe setup visualc

\msys\1.0\bin\mingw32-make.exe

2012年3月14日水曜日

WinDbgが発する「Failed to load data access DLL, 0x80004005」を無理やり回避した方法

方針:
  • 欲しい mscordacwks.dll が無いと言っているので、欲しくない mscordacwks.dll で代用してみます。

手順:
  1. [File]→[Symbol File Path...] にて、正しいパスを設定しているかどうかを確認します。

    例:
    cache*C:\DL.Symbols;SRV*http://msdl.microsoft.com/download/symbols

    C:\DL.Symbolsは、正しいシンボルファイル置き場に書き換えてください。

    Symbol File Pathを書き換える時は、WinDbgの起動直後にするのが良いです。

    また、何回も設定・終了・起動をして見て、きちんと書き換えられているかどうか、確認するのが良いです。
     
  2.  [File]→[Open Crash Dump...]で、開きます。
     
  3. .load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll
    • (.load は Meta-Commands の 1 つです)
  4. !Threads
    Failed to load data access DLL, 0x80004005
    Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
                2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                    in the version directory
                3) or, if you are debugging a dump file, verify that the file 
                    mscordacwks___.dll is on your symbol path.
                4) you are debugging on the same architecture as the dump file.
                    For example, an IA64 dump file must be debugged on an IA64
                    machine.
    
  5. .cordll -ve -u -l 
    • (.cordll は Meta-Commands の 1 つです)
  6. !Threads
    CLRDLL: Unable to get version info for 'C:\DL.Symbols\mscorwks.dll\4E154C985a9000\mscordacwks.dll', Win32 error 0n87
    CLRDLL: Unable to find mscordacwks_x86_x86_2.0.50727.3625.dll by mscorwks search
    CLRDLL: Unable to find 'mscordacwks_x86_x86_2.0.50727.3625.dll' on the path
    CLRDLL: ERROR: Unable to load DLL mscordacwks_x86_x86_2.0.50727.3625.dll, Win32 error 0n2
    Failed to load data access DLL, 0x80004005
    Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
                2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                    in the version directory
                3) or, if you are debugging a dump file, verify that the file 
                    mscordacwks___.dll is on your symbol path.
                4) you are debugging on the same architecture as the dump file.
                    For example, an IA64 dump file must be debugged on an IA64
                    machine.
    You can also run the debugger command .cordll to control the debugger's
    load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
    If that succeeds, the SOS command should work on retry.
    If you are debugging a minidump, you need to make sure that your executable
    path is pointing to mscorwks.dll as well.
    
    • (!Threads または !sos.Threads は SOS.dll (SOS デバッガー拡張) コマンドの 1 つです)
  7. コマンドプロンプトにて:
    COPY C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll C:\DL.Symbo
    ls\mscorwks.dll\4E154C985a9000\mscordacwks.dll
            1 個のファイルをコピーしました。
    
  8. .cordll -ve -u -l
     
  9. !Threads
    CLRDLL: Loaded DLL C:\DL.Symbols\mscorwks.dll\4E154C985a9000\mscordacwks.dll
    ThreadCount: 4
    UnstartedThread: 0
    BackgroundThread: 1
    PendingThread: 0
    DeadThread: 2
    Hosted Runtime: no
                                          PreEmptive   GC Alloc           Lock
           ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception
       0    1 25a4 00163db0      a020 Enabled  015233a8:01524fc4 00160250     0 MTA System.Net.WebException (014fb184)
       2    2 3594 00170370      b220 Enabled  00000000:00000000 00160250     0 MTA (Finalizer)
    XXXX    3    0 001a52a0      9820 Enabled  00000000:00000000 00160250     0 Ukn
    XXXX    4    0 00212670   1801820 Enabled  00000000:00000000 00160250     0 Ukn (Threadpool Worker) 
    

※ google-code-prettifyを組み込み、表示を最適化しました。

2012年3月7日水曜日

php5.4の日本語ファイル名問題:パッチ編

*パッチにつきましては、#61315をご覧ください。#61309のパッチも含んでいます。

安定していると思われるphp5.2を常用していますが、そろそろ新機能目当てでphp5.4に乗り換えようと思いました。

そこで、実際に乗り換えてみました。

ドカン!

色々問題が出ました(^^;
エラーや警告や厳密性チェック報告の嵐です。

ここで重大な問題が…
php5.2では問題なかった、「ソ」や「表」を含むファイル名やフォルダ名が、php5.4になって通らなくなっていました。

statやscandir等について、ファイル名称の組み合わせ等で機能しない場合が有りますよという問題点が、乗り換え後に判明すると結構困るものです(^^;

そこで急場しのぎで動くモノを作ろうと、stepbystepを参考にしながら、ビルド環境を構築いたしました。

開発・デバッグし、対策を打ちました。

本家にパッチも投稿させて頂きました。

しかし、悲しいかな両方とも[Opn->Dup]に。つまり「オープン→重複投稿」決裁に失墜です… orz

投稿した報告はこちらの2通です:
Bug #61309: DBCS included UNC path broken due to incorrect toupper usage
Bug #61315: stat() fails with specific DBCS characters

#61309の方では、次のような回答を:

New Comment:
 We already have reports about that.
 Full unicode/wildchar support is being worked on.
新しいコメント:
 我々は既にその問題についての報告を受けています。
 フルunicode/wildchar対応をしているところです。

#61315の方では、次のような回答を頂きました:

New Comment:
 Same as before, a feature request is being worked on.
 please do not report one bug for every single file function about the same
problem.


新しいコメント:
 前回と同様です。機能要望については対応しています。
 同じ問題に関して、一つのファイル関数ごとに、一つのバグを報告するのはやめてください。

怒られてしまいました。orz

先様の心証をにわかに悪くした感じです。(^^;

参考までにパッチを投稿しています。

同じ境遇の方がいらっしゃいましたら、ご活用くださいませ。

但し、無保証・無責任でのご提供になります。申し訳ございませんm(_ _)m

2012年2月9日木曜日

.NETプログラム例外落ちイベント(CLR20r3)を読み取る

.NETで作ったプログラムが例外落ちしますと、イベントビューアに記録が残ります。この情報をどのようにして読み取っていくか、につきまして。例:

ログの名前: Application
ソース: Windows Error Reporting
日付: 2012/02/09 14:27:58
イベント ID: 1001
タスクのカテゴリ: なし
レベル: 情報
キーワード: クラシック
ユーザー: N/A
コンピューター: DD5
説明:
障害バケット 、種類 0
イベント名: CLR20r3
応答: 使用不可
Cab ID: 0

問題の署名:
P1: wazato.exe
P2: 1.0.0.0
P3: 4f335959
P4: wazato
P5: 1.0.0.0
P6: 4f335959
P7: 4
P8: 10
P9: wazato.WazatoException
P10:


P1からP9までの意味する所につきましては、情報源が見つかりました。

How do you read a runtime (CLR20r3) error report?
http://social.msdn.microsoft.com/Forums/ar/clr/thread/eabef2f0-631b-41b8-91f1-431bbcb9b4df

clr20r3 from a window's service calling a dot net dll
http://social.msdn.microsoft.com/forums/en-US/clr/thread/3fca118c-cbba-4be8-ac64-02af7a4ec3ca/

要約しますと:

P1: exeファイル名の名前(32文字制限付き)
P2: exeファイルのアセンブリ バージョン
P3: exeファイルのタイムスタンプ(16進数)… new DateTime(1970, 1, 1).AddSeconds(P3).ToLocalTime()
P4: 欠陥アセンブリの名前(64文字制限付き)
P5: 欠陥アセンブリのバージョン
P6: 欠陥アセンブリのタイムスタンプ(16進数)… new DateTime(1970, 1, 1).AddSeconds(P6).ToLocalTime()
P7: 欠陥アセンブリの型とメソッド(16進数)。MethodDef
P8: 欠陥メソッドのIL命令(16進数)。オフセット
P9: スローされた例外の種類(32文字制限付き)

P9の文字列は長い場合、末尾のExceptionを省略してみたり、160ビット位(32進数×32桁)のハッシュ値にされたりしてしまいます。

ハッシュ関数はSHA-1か何かかと思いますが、未だ計算方法は判っていません。

P7とP8につきまして:

ildasmを使います。

[ファイル]→[ダンプ]で、.ilファイルを出力できます。このファイルを見ながら検証していきます。

P7が4。
上から見て4番目のメソッドかなとも思いますが、確証は有りません。
MemberInfo.MetadataToken の一部を抽出している模様です。
Assembly.LoadFile(P4_Assembly).GetModules()[0].ResolveMethod(0x06000004);

このようなコードで、対象メソッドの情報がゲットできるようです。

ildasm を用いる場合、Ctrl+M または [表示]→[メタ情報]→[表示!] で、一覧表示。
06000004 を探します。
TypeDef #1 (02000002)
-------------------------------------------------------
    TypDefName: wazato.Program  (02000002)
    Flags     : [NotPublic] [AutoLayout] [Class] [Abstract] [Sealed] [AnsiClass] [BeforeFieldInit]  (00100180)
    Extends   : 01000001 [TypeRef] System.Object
    Method #1 (06000001) 
    -------------------------------------------------------

    ...


    Method #4 (06000004) [ENTRYPOINT]
    -------------------------------------------------------
        MethodName: Main (06000004)
        Flags     : [Private] [Static] [HideBySig] [ReuseSlot]  (00000091)
        RVA       : 0x00002056
        ImplFlags : [IL] [Managed]  (00000000)
        CallCnvntn: [DEFAULT]
        ReturnType: Void
        No arguments.
        CustomAttribute #1 (0c000010)
        -------------------------------------------------------
            CustomAttribute Type: 0a000010
            CustomAttributeName: System.STAThreadAttribute :: instance void .ctor()
            Length: 4
            Value : 01 00 00 00                                      >                <
            ctor args: ()


P8が10。IL_0010を探します。丁度throwしているのが判ります。

...
  .method private hidebysig static void A() cil managed
...
  .method private hidebysig static void B() cil managed
...
  .method private hidebysig static void C() cil managed
...
  .method private hidebysig static void  Main() cil managed
  {
    .entrypoint
    .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
    // コード サイズ       17 (0x11)
    .maxstack  8
    IL_0000:  call       void [System.Windows.Forms]System.Windows.Forms.Application::EnableVisualStyles()
    IL_0005:  ldc.i4.0
    IL_0006:  call       void [System.Windows.Forms]System.Windows.Forms.Application::SetCompatibleTextRenderingDefault(bool)
    IL_000b:  newobj     instance void wazato.WazatoException::.ctor()
    IL_0010:  throw 
  } // end of method Program::Main

ちなみにC#のソースコードはこうです:
using System;
using System.Collections.Generic;
using System.Windows.Forms;
using System.IO;
namespace wazato {
    static class Program {
        static void A() { }
        static void B() { }
        static void C() { }
        /// <summary>
        /// アプリケーションのメイン エントリ ポイントです。
        /// </summary>
        [STAThread]
        static void Main() {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            throw new WazatoException();       
        }
    }
    public class WazatoException : ApplicationException {
    }
}

[2022/06/01 追記]

.NET Framework 4.x のアプリで、クラッシュダンプを作成する方法がわかりました。

Visual Studio 2022 にて、クラッシュダンプファイルの内容を確認できました。

WinDbg のコマンドライン ツール CDB を使って、クラッシュダンプの stack trace を覗く方法です。


2012年1月18日水曜日

Reg-Free COM on .NET 2.0の実践

.NET 2.0 C#から、MFCで作ったようなCOM DLLを、レジストリに登録しないで呼び出す方法を、備忘したいと思います。
MFCにはCOleDataSourceクラスとか、OLEと連携する上で役立つクラスが多数有ります。

これらを.NETだけで実現しようとすると、膨大な手数になります。

C#でドラッグ・アンド・ドロップできるアプリ(バックアップの復元ソフト)を作る際に、活用できました。

具体的な手法は又の機会に譲るとして、ここでは要素技術のみを列挙いたします:

Handling Shell Data Transfer Scenarios
  FILEDESCRIPTOR
  FILECONTENTS
IAsyncOperation

Registration-Free Activation of COM Components: A Walkthrough
  Assembly Manifests

手順:

マニフェストファイルを用意します。紫色の部分を変えていきます。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
      type="win32"
      name="DiffBkRestore"
      processorArchitecture="x86"
      version="1.0.0.0"
      />
  <file name="VFCopy.dll">
    <comClass clsid="{8FADBC22-CF67-4AEE-9B67-451C106B187E}" threadingModel="Apartment" />
  </file>
</assembly>


mt.exeでexeの中に入れ込みます。外付けのmanifestファイルでは、Reg-Freeが機能しませんでした。
紫色の部分を変えます。

mt.exe -manifest DiffBkRestore.manifest -outputresource:bin\x86\release\DiffBkRestore.exe;#1

私はNSISでセットアップを構築しています。NSISのビルド実行時にmt.exeが動くように作りこみするのも絶妙な手でしょう。

!system '"C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\mt.exe" -manifest DiffBkRestore.manifest -outputresource:bin\x86\release\DiffBkRestore.exe;#1' = 0
;C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\mt.exe
;C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\Bin\mt.exe
;C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\mt.exe

mt.exeのパスが大量にメモってあるのは、環境が変わった際に探しやすいようにする為です。

where mt.exeで探してきました。

NSISでは、!systemでシェルコマンドを実行できます。失敗したらビルドが停止するように、" = 0"を最後に足しています。指定しないと失敗しても止まりません→ほぼ確実に見落します。

後、注意点として、processorArchitecturex86等に固定しないといけません。

.NETのアセンブリは、x86でビルドしましょう。

Any CPUでビルドしてしまうと、64ビットWindowsでは、x64で起動してしまいます。これではx86で作ったCOM DLLを読み込みできません。具体的には、BadImageFormatExceptionが発生すると思います。