盒子论坛 v2.1

具体报错如下：

无法定位程序输入点 DeriveAppContainerSidFromAppContainerName 于动态链接库 C:\Windows\SYSTEM32\UIAutomationCore.dll 上

不同权限下，光标切至TEdit，运行代码会有不同吗？

只是简单的放个TEdit在Form上，当光标移到Edit时，便报如上错误。Win7下能正常运行。

断断续续做了5天的测试了，基本确定问题在权限上，之前通过各种配置权限，已经能正常使用，便回过头整理思路，却无法再次解决问题（另一虚拟机）。做过的尝试太多，记不清什么样的组合配置可以解决问题了，无法再次解决相同的问题。求对Windows权限控制熟悉，或是有碰到过类似问题的朋友点拨。
----------------------------------------------
-

作者：

wang_80919 (Flying Wang)	★☆☆☆☆	-
	普通会员

2017/1/16 17:48:47

1楼：

C:\Windows\SYSTEM32 在 32BIT 系统上没啥。
在 64BIT 系统上，您的 EXE 也必须是 64BIT的。否则就会去
C:\Windows\SysWOW64 找DLL。
----------------------------------------------
(C)(P)Flying Wang

作者：

myso (unver)	★☆☆☆☆	-
	盒子活跃会员

2017/1/16 20:46:26

2楼：

请把用户名改为administrator
----------------------------------------------
-我是一只菜菜鸟.

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/17 9:20:44

3楼：

@wang_80919
谢谢指点，做测试确定了你的说法。

报错时明确指出了目录“C:\Windows\SYSTEM32”，你是如何想到其实是去“C:\Windows\SysWOW64”找DLL的呢？

另如果EXE是64BIT的，是否会去System找DLL，而不是System32？当然这些问题我会去百度，但是还是要问一下，是否有系列的书本可以获取这些知识，而不是散落在互联网上的经验和知识点。

再次谢谢你的答凝，解燃眉之急。
----------------------------------------------
-

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/17 9:22:07

4楼：

@myso

谢谢指点，单纯的切换用户我用做过实验，确定无法解决问题。楼上给出了答案，你我一起学习吧。
----------------------------------------------
-

作者：

wang_80919 (Flying Wang)	★☆☆☆☆	-
	普通会员

2017/1/17 9:28:00

5楼：

1 我说的不一定有用。
2 这些知识，网上的确容易搜索到。书本就不知道了，十几年没看书了。
3 也许您的问题和 DLL 位置没啥关系。

不知道，您的问题，具体怎么解决的。
----------------------------------------------
(C)(P)Flying Wang

作者：

speedbin (speedbin)	★☆☆☆☆	-
	盒子活跃会员

2017/1/17 9:36:05

6楼：

这叫文件重定向。32位应用程序运行在64位系统上，用到的DLL都在WOW64，只有64位运行在64位下才是system32，32位程序安装在64位上默认系统会使安装程序安装到Program files(x86)，64位的才是program files。
一般你调用DLL 不用使用绝对路径，如果系统上32位放在system32里，如果是64位放在WOW64里
----------------------------------------------
-

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/17 10:04:19

7楼：

@wang80919
目前还没有彻底解决，但你指的方向对了，我通过拷贝“System32”目录下的UIAutomationCore.dll 到 “C:\Windows\SysWOW64”，程序确实是正常了，至少错误没有再报。是否还存在其它问题，如何彻底解决，我正在尝试中，解决了再来回复。
----------------------------------------------
-

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/17 10:05:46

8楼：

@speedbin

谢谢告知检索关键字“文件重定向”
----------------------------------------------
-

作者：

wang_80919 (Flying Wang)	★☆☆☆☆	-
	普通会员

2017/1/17 10:10:54

9楼：

如果拷贝 DLL 就正常，说明这个系统安装的有问题，不完整。

任何完整的系统，同一个系统用的 DLL 必然存在两个版本。
而且不会放错位置，因为那是微软自己安装的，微软不会出这种低级错误。

另外一种可能是，有病毒，破坏了这些 DLL 。
----------------------------------------------
(C)(P)Flying Wang

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/18 16:34:30

10楼：

@wang_80919
我是用“System32”目录下的同名文件覆盖“SysWOW64"下的UIAutomationCore.dl（这里有个疑问,32位程序可以调用64位DLL？），虽然不报错了，但并没有真正的解决问题

我查MSDN了解到 DeriveAppContainerSidFromAppContainerName 的作用是

“取得指定的配置文件的SID。” security identifier --- SID = 安全标识符

在Win8及Win8后版本上才支持，这解释了Win10才调用DeriveAppContainerSidFromAppContainerName的问题。同时我猜这个只提供在64位DLL中，所以覆盖同时文件后不会再报找不到xxx的错误。

要完全解决问题，我的思路如下：
1.能否能过设定让操作系统不要调用 DeriveAppContainerSidFromAppContainerName，也就是不做权限检查。我之前的测试应该是达到了此效果，只是测试操作太多，无法提取方法重复解决问题。

另外，这里有个疑问，放个把光标切到TEdit这么简单的操作要检查权限？
----------------------------------------------
-

作者：

bahamut8348 (leonna)	★☆☆☆☆	-
	普通会员

2017/1/18 16:48:57

11楼：

win x64系统里， system32目录下是x64的库，而syswow64下则是x86的库。
而x64和x86是不能混合加载库的，也就是说x64只能加载x64的库，x86只能加载x86的库。
所以，看楼主的现象应该是syswow64下的库损坏导致的。
----------------------------------------------
--

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/18 17:27:58

12楼：

@ bahamut8348
我用三台实体机和3台虚拟机测试的，库损坏不太可能，应该是32位的程序调用

DeriveAppContainerSidFromAppContainerName，调用的是syswow64目录下的DLL，而
DeriveAppContainerSidFromAppContainerName 应该只提供在64位的DLL中，于是报错。

个人觉得理论上32位程序不应该调用 DeriveAppContainerSidFromAppContainerName的。
----------------------------------------------
-

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/18 17:31:36

13楼：

刚测试发现，将EXE拷贝到其它目录（例如：C盘根目录）可以正常运行。
----------------------------------------------
-

作者：

crystalmoon (crystalmoon)	★☆☆☆☆	-
	盒子活跃会员

2017/1/19 8:48:26

14楼：

??????我是用“System32”目录下的同名文件覆盖“SysWOW64"下的UIAutomationCore.dll
....
你牛，我不知道说什么好了，这么随便覆盖？System32对应 64位的，SysWOW64对应32位的。。。。不要乱弄。。。。你从其它干净的系统里拷贝过来一份吧。
如果你是32位的程序，正常情况下实际就不会调用C:\Windows\SYSTEM32\UIAutomationCore.dll这个的。。。。系统会自动引导它到SysWOW64，除非你通过一个api关闭了重定位功能。

如果你的UIAutomationCore.dll是32位的，那么正确姿势应该是删除System32下的。保留SysWOW64下的就可以。。。如果是64位的，则反之
----------------------------------------------
-

作者：

bahamut8348 (leonna)	★☆☆☆☆	-
	普通会员

2017/1/19 9:29:14

15楼：

看了一下msdn的api说明，并没有说明是x64才有的函数。兰州说用了几个虚拟机测试都有问题，是不是都是同一个镜像呢？
win10我从刚发正式版就在用，没碰过这种问题啊。
----------------------------------------------
--

作者：

wang_80919 (Flying Wang)	★☆☆☆☆	-
	普通会员

2017/1/19 9:59:11

16楼：

这个 DLL，我WIN10 系统下 system32 syswow64 各有一份，肯定不能互相覆盖。
----------------------------------------------
(C)(P)Flying Wang

作者：

speedbin (speedbin)	★☆☆☆☆	-
	盒子活跃会员

2017/1/19 17:17:08

17楼：

x64系统下system32里面的文件是64位的，wow64才是32位的，两个文件是不一样的，同名但是一个64位，一个32位，当然不能直接替换。
----------------------------------------------
-

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/21 9:53:40

18楼：

@bahamut8348 是同一镜像，但另三台实体机，包括家庭版和专业版加入测试
----------------------------------------------
-

作者：

gdtdu (政)	★☆☆☆☆	-
	普通会员

2017/1/21 9:56:47

19楼：

64位文件覆盖32位文件，最终效果其实就是删除32位的文件了。目前的解决方法是删除32位的文件，可以暂时解决问题，但删除系统文件，终不放心。

没有新的思路，不打算再关注此问题了，日后如有发现再来留言。
----------------------------------------------
-

信息

登陆以后才能回复