次のコードは、「指定されたレジストリキーは存在しません」というメッセージとともにIOExceptionをスローします。
HttpClient client = new HttpClient();
Uri uri = new Uri("http://www.google.com");
client.GetAsync(uri);
これはメインのコンソールアプリにあります。 mscorlib.dll!Microsoft.Win32.RegistryKey.Win32Error(int errorCode、string str)によってエラーがスローされているようです。このエラーがスローされる理由や、デバッグを開始する方法がわかりません。
スタックトレースの編集:
microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode、String str)で
それはたった1行であり、内部例外などはありません。
呼び出しスタックは次のとおりです。
mscorlib.dll!Microsoft.Win32.RegistryKey.Win32Error(int errorCode, string str) + 0x189 bytes
mscorlib.dll!Microsoft.Win32.RegistryKey.GetValueKind(string name) + 0x7f bytes
System.dll!System.Net.HybridWebProxyFinder.InitializeFallbackSettings() + 0x9e bytes
[Native to Managed Transition]
[Managed to Native Transition]
System.dll!System.Net.AutoWebProxyScriptEngine.AutoWebProxyScriptEngine(System.Net.WebProxy proxy, bool useRegistry) + 0xd0 bytes
System.dll!System.Net.WebProxy.UnsafeUpdateFromRegistry() + 0x2c bytes
System.dll!System.Net.Configuration.DefaultProxySectionInternal.DefaultProxySectionInternal(System.Net.Configuration.DefaultProxySection section) + 0x1d8 bytes
System.dll!System.Net.Configuration.DefaultProxySectionInternal.GetSection() + 0xec bytes
System.dll!System.Net.WebRequest.InternalDefaultWebProxy.get() + 0xcc bytes
System.dll!System.Net.HttpWebRequest.HttpWebRequest(System.Uri uri, System.Net.ServicePoint servicePoint) + 0xdf bytes
System.dll!System.Net.HttpWebRequest.HttpWebRequest(System.Uri uri, bool returnResponseOnFailureStatusCode, string connectionGroupName, System.Action<System.IO.Stream> resendRequestContent) + 0x2b bytes
System.Net.Http.dll!System.Net.Http.HttpClientHandler.CreateAndPrepareWebRequest(System.Net.Http.HttpRequestMessage request) + 0x59 bytes
System.Net.Http.dll!System.Net.Http.HttpClientHandler.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) + 0xf4 bytes
System.Net.Http.dll!System.Net.Http.HttpMessageInvoker.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) + 0x4f bytes
System.Net.Http.dll!System.Net.Http.HttpClient.SendAsync(System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) + 0x13e bytes
System.Net.Http.dll!System.Net.Http.HttpClient.GetAsync(System.Uri requestUri, System.Net.Http.HttpCompletionOption completionOption) + 0xc bytes
ConsoleServiceTest.exe!ConsoleServiceTest.Program.Main(string[] args) Line 20 + 0x17 bytes C#
[Native to Managed Transition]
[Managed to Native Transition]
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() + 0x5a bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x285 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x9 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x57 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x51 bytes
[Native to Managed Transition]
これは、.NET Frameworkの最近のセキュリティ更新プログラムによるものと思われます: MS12-074:.NET Frameworkの脆弱性により、リモートでコードが実行される可能性があります:2012年11月13日(KB 2745030)
すべては、Webプロキシ解決の次のコードに要約されます。
[RegistryPermission(SecurityAction.Assert, Read=@"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework")]
private static void InitializeFallbackSettings()
{
allowFallback = false;
try
{
using (RegistryKey key = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\.NETFramework"))
{
try
{
if (key.GetValueKind("LegacyWPADSupport") == RegistryValueKind.DWord)
{
allowFallback = ((int) key.GetValue("LegacyWPADSupport")) == 1;
}
}
catch (UnauthorizedAccessException)
{
}
catch (IOException)
{
}
}
}
catch (SecurityException)
{
}
catch (ObjectDisposedException)
{
}
}
ご覧のとおり、KBの記事に記載されている特定のレジストリキーをチェックします。また、例外は内部でキャッチされますが、Visual StudioのデバッグオプションでFirst Chance Exceptionsを有効にしているため、例外が表示されることに注意してください。
この例外を表示したくない場合は、指定されたレジストリキーに値0
:
Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
DWORD (32-bit) Value name: LegacyWPADSupport
Value data: 0
および64ビットマシン上の32ビットプロセスの場合:
Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework
DWORD (32-bit) Value name: LegacyWPADSupport
Value data: 0
Ligazの回答に同意し、このバグに関するConnectの問題を記録しました: https://connect.Microsoft.com/VisualStudio/feedback/details/773666/webrequest-create-eats-an-ioexception- on-the-first-call#details
次を.regファイルに保存し、レジストリにインポートして、このエラーが発生しないようにします。
Windows Registry Editor Version 5.00
; The following value prevents an IOException from being thrown and caught
; by System.Net.HybridWebProxyFinder.InitializeFallbackSettings() (in System.dll)
; when WebRequest.Create is first called. By default the "LegacyWPADSupport"
; value doesn't exist, and when InitializeFallbackSettings calls GetValueKind,
; an IOException is thrown. This adds the value with its default of false to
; prevent the exception.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"LegacyWPADSupport"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework]
"LegacyWPADSupport"=dword:00000000
何らかの理由で、HttpClient
コードはレジストリでプロキシ設定を探しているため、キーを開けません。コードを見ると、HKCUを開き、次のキーのいずれかに順番に移動しようとしていることがわかります。
"HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\Connections"
"HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\Connections"
"HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\CurrentVersion\\Internet Settings"
これら3つのうちの1つは、プロセスがアクセスできないキーである可能性があります。 1つの可能な修正方法は、プロキシ設定の自動検出を無効にすることです。
それ以外の場合は、ロードするキーを正確に把握する必要があり、2つのステップでそれを行います。
- 開いたら、有効になっている場合はキャプチャを無効にします(虫眼鏡に赤いXが付いているはずです)。
- プロセス名でフィルタリングを開始します。
- レジストリエントリを除くすべてのオプションを選択解除する
- キャプチャを有効にします(虫眼鏡をクリックします)
- アプリケーションを実行する
- ログで問題のあるエントリを見つけ、ダブルクリックして開いていたキーを確認します
問題のあるキーを特定したら、アプリケーションがそのキーにアクセスできない理由を突き止めることができます。おそらく、アプリケーションの名前が何らかの兆候である場合、サービスが実行されているユーザーアカウントにはレジストリキーへのアクセス権がありません。