Question

我们的.NET应用程序存在x文件问题。或者说，混合使用Win32和.NET应用程序。

当它试图与Oracle通信时，它就会死掉。消失。走向天空中的大黑洞。没有事件日志消息，没有例外，没有任何内容。

如果我们只是要求应用程序与MS SQL Server进行通信，这样可以将OracleConnection和相关类的用法替换为SqlConnection及相关类，则可以按预期工作。

今天我们取得了突破。

出于某种原因，客户已经发现通过将所有应用程序文件放在他桌面上的目录中，它也可以像Oracle一样工作。将目录向下移动到驱动器的根目录，或者在C：\ Temp中，或者好吧，稍微移动一下，使崩溃重新出现。

基本上，如果从桌面上的目录运行，则应用程序可以100％重现，如果从root目录运行则失败。

今天我们发现计算的差异是否与目录名中有空格有关。

所以，这些目录可行：

C:\Program Files\AppDir\Executable.exe
C:\Temp Lemp\AppDir\Executable.exe
C:\Documents and Settings\someuser\Desktop\AppDir\Executable.exe

而这些不会：

C:\CompanyName\AppDir\Executable.exe
C:\Programfiler\AppDir\Executable.exe      <-- Program Files in norwegian
C:\Temp\AppDir\Executable.exe

我希望有人在阅读此内容后会看到类似的行为，并且有一个“啊哈，你需要在oracle glitz驱动程序配置上或其他类似的东西上扭曲。”

任何？

跟进＃1：好的，我现在处理了procmon输出，当我点击试图打开触发级联故障的窗口的按钮时，这两个文件都被我注意到了他们主要跟踪，两个文件顶部附近有一些细微差别，他们跟踪了很长时间。

然而，当一次运行失败时，另一次运行继续进行，日志输出的下几行是这些：

ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 274 432, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 233 472, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O

在此之后，工作运行继续执行，另一个在线程关闭并且应用程序关闭之前触摸mscorwks.dll文件几次。因此，失败的运行不会触及上述文件。

后续行动＃2 ：我想尝试升级oracle客户端驱动程序，但10.2.0.1显然是Windows 2003服务器和XP客户端可用的最高版本。

后续行动＃3：好吧，我们最终得到了一个黑盒解决方案。基本上我们发现问题出在与XPO和Oracle相关的地方。 XPO有一个它管理的系统表，称为XPObjectType，有三列：Oid，TypeName和AssemblyName。由于我们在与之交谈的数据库中配置了Oracle，因此列名称为OID，TYPENAME和ASSEMBLYNAME。这通常不是问题，除了XPO直接与架构信息对话并检查表是否有正确的列名，XPO不处理大小写差异，因此它看到一个XPObjectType表有三个未知列，没有那些预期的那些。

现在我真的不知道XPO做了什么，但是如果我删除了这个表，并使用正确的情况重新创建它，在所有列名称周围使用双引号来使情况正确，问题不会解决起来。

文件夹名称中的空间到底在哪里，我仍然不知道，但这个问题有两层：

阻止应用程序崩溃，我们的客户，短期解决方案
修复错误，长期解决方案

现在第1层已经解决，第2层将暂时放回队列并确定优先顺序。无论如何，我们的数据层面临着一些更大的变化，所以这可能不是我们需要解决的问题，至少如果我们所有的Oracle客户都验证表修复实际上已经解决了这个问题。

我会接受Dave Markle的答案，因为虽然Process Monitor（文件监视器的大哥）没有真正查明问题，但我能够用它来确定在用户的断点之后 - XPO为此表构建查询的代码，在关闭应用程序关闭的所有条目之前没有发生I / O，这让我相信这个表是罪魁祸首，或者至少影响了问题

如果我能找到真正的原因，我会更新帖子。

Answer 1

这就是我要做的。首先，TRIPLE-检查您是否看到了您认为正在看到的行为。我可以通过不使用System.IO.Path来连接路径来反过来看到这种情况，但不像你看到的那样。三重检查文件权限是否有意义。

接下来，从MS下载Filemon并观察文件系统上发生的情况，因为您的程序遇到了这些问题。您可以过滤掉特定的文件活动（例如删除防病毒文件活动），以便在执行此操作时使一切看起来更清晰。使用FileMon查找程序的成功案例和错误案例的文件访问错误。这应该指向您正在访问的文件并导致问题。例如，如果您看到FILE_NOT_FOUND错误访问无意义的文件名，您可以放心，您或供应商做错了什么，可能会导致您的问题......

Answer 2

您应该看看是否可以使用仅尝试打开与Oracle的连接的简单应用程序来重现问题。这样您就可以100％确定问题出在OracleConnection或Oracle驱动程序上，而不是您自己的代码。

Answer 3

你应该获得坚持不懈的奖章！。

“正是XPO现在所做的事情我没有   真的知道，但如果我放弃了这个   表，并用右边重新创建它   案例，使用双引号   得到案例的列名   没错，问题不会出现。

文件夹中的空间正好在哪里   名字进入这个，我还是没有   主意“

我在名称中使用空格得到的问题是它们通常将空格前的位解释为名称，将其余部分解释为参数。如果是这种情况，那么使用普通名称可以看到“C \ Temp”并且它是一个目录。使用间隔名称，它将获得“C：\ Program Files”，查找“C：\ Program”并且不存在。例如，它会覆盖“C：\ Temp”，但会成功写入“C：\ Program”。想知道如果有一个名为“C：\ Program”的文件或目录，它是否仍然会失败“C：\ Program Files”

Answer 4

我怀疑oracle客户端是诚实的。有一个类似于令人沮丧的性质的问题。

如果我们安装在64位计算机上，即使应用程序是32位，客户端也会在连接到oracle时停止启动。我们最终跟踪了一个事实，即某个oracle客户端（Ora 10在路径中有括号问题，因此在程序文件下运行的程序可以在程序文件（x86）下运行导致崩溃。更新机器使用11G客户端修复了这个问题，但是还有一些来自metalink的补丁，这些补丁都不是直接可用的。你的情况很奇怪，你没有例外但是将应用程序移动到新文件夹的行为以类似的方式修复了问题所以它可能是相关的。

ORA-12154：TNS：无法解析指定的连接标识符要么 ORA-6413：连接未打开。

有用的链接http://blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx

以下Metalink的详细信息。

Metalink错误3807408无法使用用户名

中的引号对用户进行外部身份验证

描述如果外部验证的用户名包含'（'，'）'或'=' 那么用户无法进行身份验证。此外，如果程序名称/路径包含这些字符可能无法连接。例如： Windows客户端安装在目录“C：\ Program Files（x86）”中无法连接 ORA-12154：TNS：无法解析指定的连接标识符

此问题的标志是网络跟踪（级别16）显示问题字符/被“？”取代在踪迹中。

解决方法对于身份验证问题：更改用户名，要么不要对这些用户使用远程OS身份验证

除非可执行路径包含空格，否则应用程序在与oracle通信时会崩溃

4 个答案: