此问题可以部分解决。框架异常代码根据当前线程语言环境从其资源加载错误消息。在某些情况下，这是在访问Message属性时发生的。

对于这些例外情况，您可以通过在记录日志时将线程语言环境短暂地切换到en-US来获得消息的完整的美国英语版本（预先保存原始用户语言环境，然后立即恢复它）。

在单独的线程上执行此操作甚至更好：这可以确保不会有任何副作用。例如：

try
{
  System.IO.StreamReader sr=new System.IO.StreamReader(@"c:\does-not-exist");
}
catch(Exception ex)
{
  Console.WriteLine(ex.ToString()); //Will display localized message
  ExceptionLogger el = new ExceptionLogger(ex);
  System.Threading.Thread t = new System.Threading.Thread(el.DoLog);
  t.CurrentUICulture = new System.Globalization.CultureInfo("en-US");
  t.Start();
}

ExceptionLogger类的外观类似于：

class ExceptionLogger
{
  Exception _ex;

  public ExceptionLogger(Exception ex)
  {
    _ex = ex;
  }

  public void DoLog()
  {
    Console.WriteLine(_ex.ToString()); //Will display en-US message
  }
}

但是，正如Joe在对此答复的较早版本的评论中正确指出的那样，在引发异常时，已经从语言资源中（部分）加载了某些消息。

例如，这适用于抛出ArgumentNullException（“
foo”）异常时生成的消息的“参数不能为null”部分。在这种情况下，即使使用上面的代码，该消息仍将（部分）本地化。

除了通过使用不切实际的技巧（例如在一开始使用en-US语言环境的线程上运行所有非UI代码）之外，您似乎无能为力：.NET
Framework异常代码没有覆盖错误消息语言环境的工具。