问题：.NET 代码从同一磁盘上的一个目录运行，但不能从另一个目录运行
我们的应用程序是混合 Win32 非托管应用程序和 .NET 2.0 托管应用程序。 Win32 部分是主要的可执行文件，它在某些时候加载和托管 .NET 2.0 运行时，并加载一些托管模块以打开新的 winforms 窗口。
我们也遇到过 CASPOL 类型的问题，但今天我们遇到了一个非常奇怪的问题，我希望有人能给我一些指示或想法，或者基本上任何真正的东西，这会引发一些有助于帮助我的东西的火花我们解决这个问题。
在通过 Citrix 访问的服务器上，如果应用程序文件位于当前登录用户（服务器/域管理员）桌面上的目录中，则程序运行正常。 .NET 窗口按预期打开。
但是，如果我们将目录移动到同一磁盘的根目录，该磁盘是服务器中的物理磁盘（因此没有 SAN 映射或任何会触发 CASPOL 命令的内容据我所知）并保持其他一切相同、相同的用户、相同的配置等。，当我们尝试调用 .NET 窗口时，应用程序会默默地崩溃。 它以消失的方式崩溃，这表明它可能类似于堆栈溢出。 我们正在考虑向应用程序的某些部分添加日志记录，以便能够弄清楚发生了什么以及在哪里发生，但我也在这里发布了这个问题。
到目前为止，我们已经验证了 CASPOL 访问列表中没有任何异常，NGEN 缓存中也没有任何异常（我在想，如果服务器所有者使用过它，可能之前的图像已损坏），并且 NGEN 缓存中没有任何异常。 GAC（我们不将 GAC 用于程序集）。
总结：
- 如果该程序从 U:\Documents and Settings\USERNAME\Desktop\directory 运行，则它可以工作
- 如果从 U:\directory 运行该程序，则它不起作用
- U: 是服务器中的物理磁盘
- 没有明显的奇怪之处NGEN 或 GAC 缓存
- 正确的 .NET 运行时已安装，我们的应用程序的正确文件已安装（如果从桌面位置运行，确实可以正常工作）
有人有任何可能有帮助的吗？
编辑：问题在这里再次询问不同/其他信息，并“解决”。
Our application is a hybrid Win32 unmanaged application and a .NET 2.0 managed application. The Win32 part is the main executable, which at some point loads and hosts the .NET 2.0 runtime and loads some managed modules to open new winforms windows.
We've had our share of CASPOL-type problems, but today we have a very odd problem and I'm hoping someone can give me some pointers or ideas, or basically just anything really, that would trigger a spark of something that would help us resolve this.
On a server, accessed through citrix, if the application files are located in a directory located on the desktop of the currently logged on user, which is a server/domain administrator, the program runs fine. The .NET windows open as expected.
However, if we move the directory to the root of the same disk, which is a physical disk in the server (so no SAN mapping or anything that would trigger a CASPOL command to my knowledge) and keep everything else the same, same user, same configuration, etc., the application silently crashes when we try to invoke the .NET windows. It crashes by way of just disappearing, which suggests it might be something like a stack overflow. We're looking into adding logging to some parts of the app to perhaps be able to figure out what happens, and where, but I'm posting this question here as well.
So far we've verified that there are no oddities in the CASPOL access list, nothing odd in the NGEN cache (I was thinking perhaps there was corrupted images from before, if the server owner had played with it), and no oddities in the GAC (we don't use GAC for the assemblies).
Summarized:
- If the program is run from U:\Documents and Settings\USERNAME\Desktop\directory, it works
- If it is run from U:\directory, it doesn't
- U: is a physical disk in the server
- No apparent oddities in NGEN or GAC caches
- The right .NET runtime is installed, the right files for our application has been installed (and indeed work fine if run from the desktop location)
Anyone with anything that might help?
Edit: Problem re-asked here with different/other information, and "solved".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我前段时间也遇到过这样的问题。 经过一番拉扯，我发现了问题。
使用 Process.Start() 或任何此类调用时要非常小心，因为根据您启动它的方式，它可以使用各种文件夹作为工作环境（当前路径、系统环境等）。
I had precisely such a problem some time back. After much hair pulling I found the problem.
Be very carefull when you use Process.Start() or any such calls, because depending on how you start it it can use a variety of folders as the working environment (current path, system environment, and so on.
我的第一个尝试是从 MS-Sysinternals 运行进程监视器，并查看这两种情况下的调用/结果有何不同。
也许这会给你一些提示（同一调用的不同结果，问题运行中的一些错误不是好的错误......）
你可以从 MS 下载进程监视器：
http://technet.microsoft.com/en-us/sysinternals/bb896645。 ASPX
My first stab would be to run process monitor from MS-Sysinternals, and look what calls/results are different for these two occasions.
Maybe that would give you some hints to work on (different results for the same call, some errors in the problem run that are not in the good one...)
You can download process monitor from MS:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
我的第一个想法是，您需要确保程序中没有定义相对/绝对路径来引用程序集、文件等，这些路径在您移动应用程序根目录时会造成麻烦。
My first thought is that you need to make sure there are no relative/absolute paths defined in the program for references to assemblies, files, etc. which are causing trouble when you move the application root directory.
是否有可能与用户权限有关？ 从 LUA Buglight< 运行它/a> 检查。 即使它不直接相关，该工具也可能会提供一些有用的提示。
Is it possible that its related to user priviledges? Run it from LUA Buglight to check. Even if it's not directly related, that tool may well give some useful hints.