与oracle通信时应用程序崩溃，除非可执行路径包含空格 [英] Application crashing when talking to oracle unless executable path contains spaces
问题描述
我们的.NET应用程序有一个x-files问题。或者，混合Win32和.NET应用程序。
We have an x-files problem with our .NET application. Or, rather, hybrid Win32 and .NET application.
当它尝试与Oracle通信时，它只是死了。消失。去天空中的大黑洞。没有事件日志消息，没有异常，没有任何东西。
When it attempts to communicate with Oracle, it just dies. Vanishes. Goes to the big black void in the sky. No event log message, no exception, no nothing.
如果我们只是要求应用程序与MS SQL Server交谈， Oracle连接和相关的类与SqlConnection和相关的类，它的工作原理。
If we simply ask the application to talk to a MS SQL Server instead, which has the effect of replacing the usage of OracleConnection and related classes with SqlConnection and related classes, it works as expected.
今天我们有一个突破。
由于某种原因，客户发现通过将所有应用程序文件放置在桌面上的目录中，它也与Oracle一样正常工作。将目录向下移动到驱动器的根目录，或者在C：\ Temp或者，一点点，使崩溃重新出现。
For some reason, a customer had figured out that by placing all the application files in a directory on his desktop, it worked as expected with Oracle as well. Moving the directory down to the root of the drive, or in C:\Temp or, well, around a bit, made the crash reappear.
基本上是100
今天我们发现，计算的差异是因为，如果从桌面上的目录运行，
Today we figured out that the difference that counted was wether there was a space in the directory name or not.
因此，这些目录将工作：
So, these directories would work:
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
$ b b
我希望有人看到这种情况，看到类似的行为，并有一个aha，你需要旋转frob oracle glitz驱动程序配置或类似的。
I'm hoping someone reading this has seen similar behavior and have a "aha, you need to twiddle the frob on the oracle glitz driver configuration" or similar.
任何人？
后续＃1：现在，两个文件，当我打我的按钮，试图打开触发级联失败的窗口，我注意到，他们保持大多数，两个文件的顶部附近有一些微小的差异，他们他们跟踪一个
Followup #1: Ok, I've processed the procmon output now, both files from when I hit the button that attempts to open the window that triggers the cascade failure, and I've noticed that they keep track mostly, there's some smallish differences near the top of both files, and they they keep track a long way down.
但是，当一个运行失败时，另一个继续运行，日志输出的下几行如下：
However, when one run fails, the other keeps going and the next few lines of the log output are these:
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文件几次，在线程关闭并关闭应用程序之前。因此，失败的运行不会触及上述文件。
After this, the working run continues to execute, and the other touches the mscorwks.dll files a few times before threads close down and the app closes. Thus, the failed run does not touch the above files.
后续＃2：我尝试升级oracle客户端驱动程序，但10.2.0.1显然是Windows 2003服务器和XP客户端可用的最高版本。
Followup #2: Figured I'd try to upgrade the oracle client drivers, but 10.2.0.1 is apparently the highest version available for Windows 2003 server and XP clients.
跟进＃3：好了，我们结束了一个黑盒子的解决方案。基本上，我们发现问题是与 XPO 和Oracle相关的。 XPO有一个系统表，它管理，称为XPObjectType，有三列：Oid，TypeName和AssemblyName。由于在我们谈论的数据库中配置Oracle的方式，列名称为OID，TYPENAME和ASSEMBLYNAME。这通常不是一个问题，除了XPO直接与模式信息对话，并检查表是否有正确的列名，并且XPO不处理大小写差异，所以它看到一个XPObjectType表有三个未知列和无
Followup #3: Well, we've ended up with a black-box solution. Basically we found that the problem is somewhere related to XPO and Oracle. XPO has a system-table it manages, called XPObjectType, with three columns: Oid, TypeName and AssemblyName. Due to how Oracle is configured in the databases we talk to, the column names were OID, TYPENAME and ASSEMBLYNAME. This would ordinarily not be a problem, except that XPO talks to the schema information directly and checks if the table is there with the right column names, and XPO doesn't handle case differences so it sees a XPObjectType table with three unknown columns and none of those it expects.
现在我真的不知道什么XPO，但是如果我删除这个表，并用正确的方式重新创建它，使用双引号
Exactly what XPO does now I don't really know, but if I dropped this table, and recreated it with the right case, using double quotes around all the column names to get the case right, the problem doesn't crop up.
正确的文件夹名称中的空格到这里，我仍然没有但这个问题有两层：
Exactly where the space in the folder name comes into this, I still have no idea, but this problem had two tiers:
- 停止应用程序崩溃，我们的客户，短期解决方案
- 修正错误，长期解决方案
现在解决了第一层，第二层将被放回现在的队列和优先级。我们正在对我们的数据层进行一些更大的更改，因此这可能不是我们需要解决的问题，至少如果我们所有的Oracle客户验证表修复实际上摆脱了这个问题。
Right now tier 1 is solved, tier 2 will be put back into the queue for now and prioritized. We're facing some bigger changes to our data tier anyway so this might not be a problem we need to solve, at least if all our Oracle-customers verify that the table-fix actually gets rid of the problem.
我会接受 Dave Markle 的答案，因为虽然Process Monitor（文件监视器的大哥）没有实际指出问题，我能够使用它来确定，在我的断点在用户代码中，XPO已经建立了这个表的查询，没有I / O发生，直到所有记录了应用程序关闭的条目，这导致我相信是这个表是罪魁祸首，或至少影响了问题。
I'll accept the answer by Dave Markle since though Process Monitor (the big brother of File Monitor) didn't actually pinpoint the problem, I was able to use it to determine that after my breakpoint in user-code where XPO had built up the query for this table, no I/O happened until all the entries for the application closing down was logged, which led me to believe it was this table that was the culprit, or at least influenced the problem somehow.
如果我管理
推荐答案
这里是我会做的。首先，TRIPLE - 检查您是否看到您认为您看到的行为。我可以看到这种情况发生在另一方面，不使用System.IO.Path连接路径，但不像你看到的。请仔细检查文件权限是否有意义。
Here's what I would do. First, TRIPLE-check that you're seeing the behavior you think you're seeing. I can see this happening the other way around by not using System.IO.Path to concatenate paths, but not like you're seeing it. Triple-check that the file permissions make sense.
接下来，下载 Filemon 从MS，看看在文件系统上发生了什么，因为您的程序遇到这些问题。您可以过滤掉特定的文件活动（例如，删除您的防病毒文件活动），以使一切看起来更清洁，而这样做。使用FileMon为程序的成功案例和错误情况查找文件访问错误。这应该指向你正在访问什么文件并导致问题。例如，如果您在访问无意义文件名时看到一个 FILE_NOT_FOUND 错误，您可以放心，您或供应商做错了，可能导致您的问题...
Next, download Filemon from MS and watch what's happening on the filesystem as your program hits these troubled spots. You can filter out specific file activity (removing your anti-virus file activity, for example) to make everything look a bit cleaner while you do this. Look for file access errors using FileMon for both the success case and the error case for your program. That should point you to what file's being accessed and causing the problem. For example, if you see a FILE_NOT_FOUND error accessing a nonsense filename, you can be assured that you or the vendor are doing something wrong, possibly leading to your problem...
这篇关于与oracle通信时应用程序崩溃，除非可执行路径包含空格的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
