① 如何分析堆栈出错的 dmp 文件
分析程序出错生成的 dmp 文件是事后分析的主要工作。第一步往往都是使用 WinDbg 自带的 !analyze -v 命令先进行初步分析，得到出错地址和出错堆栈后再进行详细分析。 介绍一个方法，当 !analyze -v 不好使的时候应该怎么得到出错地址和出错堆栈。 int sum(int x, int y) { __asm mov ebp, 0 return (x + y); } int sumstub(int x, int y) { int tmp = 0; printf("enter fun() …\n"); tmp = sum(x, y); printf("leave fun() …\n"); return tmp; } int main(int argc, char* argv[]) { printf("enter main() …\n"); printf("sum = %d\n", sumstub(0x1234, 0x5678)); printf("leave main() …\n"); return 0; }示例程序比较简单，在 sum 函数里面会把 ebp 清零，下面取 x 或者 y 的值时就会出错。用 WinDbg 打开出错得到的 dmp 文件，先用 !analyze -v 分析，结果如下： 0:000> !analyze -v ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* *** WARNING: Unable to verify checksum for Dump01.exe *** ERROR: Symbol file could not be found. Defaulted to export symbols for lpk.dll – *** ERROR: Symbol file could not be found. Defaulted to export symbols for Sysfer.dll – *** ERROR: Symbol file could not be found. Defaulted to export symbols for usp10.dll – *** ERROR: Symbol file could not be found. Defaulted to export symbols for imm32.dll – *** ERROR: Symbol file could not be found. Defaulted to export symbols for apphelp.dll – *** ERROR: Symbol file could not be found. Defaulted to export symbols for version.dll – *** ERROR: Symbol file could not be found. Defaulted to export symbols for advapi32.dll – *** ERROR: Symbol file could not be found. Defaulted to export symbols for shlwapi.dll – FAULTING_IP: +0 00000000 ?? ??? EXCEPTION_RECORD: ffffffff — (.exr 0xffffffffffffffff) ExceptionAddress: 00000000 ExceptionCode: 80000007 (Wake debugger) ExceptionFlags: 00000000 NumberParameters: 0 BUGCHECK_STR: 80000007 PROCESS_NAME: Dump01.exe ERROR_CODE: (NTSTATUS) 0x80000007 – { NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 DERIVED_WAIT_CHAIN: Dl Eid Cid WaitType — — ——- ————————– 0 62c.928 Unknown WAIT_CHAIN_COMMAND: ~0s;k;; BLOCKING_THREAD: 00000928 DEFAULT_BUCKET_ID: APPLICATION_HANG_HungIn_ExceptionHandler PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_HungIn_ExceptionHandler LAST_CONTROL_TRANSFER: from 7c92e9ab to 7c92eb94 FAULTING_THREAD: 00000928 STACK_TEXT: 0012f3b8 7c92e9ab 7c86372c 00000002 0012f53c ntdll!KiFastSystemCallRet 0012f3bc 7c86372c 00000002 0012f53c 00000001 ntdll!ZwWaitForMultipleObjects+0xc 0012fb38 00401dda 0012fb74 0012ffb0 0012ffc0 kernel32!UnhandledExceptionFilter+0x8e4 0012fb48 00401198 c0000005 0012fb74 0040261b Dump01!_XcptFilter+0x13e 0012ffc0 7c816fd7 011dd65c 011dd664 7ffd6000 Dump01!mainCRTStartup+0xd1 0012fff0 00000000 004010c7 00000000 00000000 kernel32!BaseProcessStart+0x23FOLLOWUP_IP: Dump01!_XcptFilter+13e 00401dda 5b pop ebx SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: Dump01!_XcptFilter+13e FOLLOWUP_NAME: MachineOwner MODULE_NAME: Dump01 IMAGE_NAME: Dump01.exe DEBUG_FLR_IMAGE_TIMESTAMP: 46de4ed1 STACK_COMMAND: ~0s ; kb FAILURE_BUCKET_ID: 80000007_Dump01!_XcptFilter+13e BUCKET_ID: 80000007_Dump01!_XcptFilter+13e Followup: MachineOwner ———分析得到的出错地址为 0，堆栈也在内核里面。很明显这次 !analyze -v 命令出问题了，需要手动分析才能得到想要的信息。 0:000> ~*kv . 0 Id: 62c.928 Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr Args to Child 0012f3b8 7c92e9ab 7c86372c 00000002 0012f53c ntdll!KiFastSystemCallRet (FPO: [0,0,0]) 0012f3bc 7c86372c 00000002 0012f53c 00000001 ntdll!ZwWaitForMultipleObjects+0xc (FPO: [5,0,0]) 0012fb38 00401dda 0012fb74 0012ffb0 0012ffc0 kernel32!UnhandledExceptionFilter+0x8e4 (FPO: [Non-Fpo]) 0012fb48 00401198 c0000005 0012fb74 0040261b Dump01!_XcptFilter+0x13e 0012ffc0 7c816fd7 011dd65c 011dd664 7ffd6000 Dump01!mainCRTStartup+0xd1 0012fff0 00000000 004010c7 00000000 00000000 kernel32!BaseProcessStart+0x23 (FPO: [Non-Fpo]) 0:000> !teb TEB at 7ffdf000 ExceptionList: 0012fb28 StackBase: 00130000 StackLimit: 0012a000 SubSystemTib: 00000000 FiberData: 00001e00 ArbitraryUserPointer: 00000000 Self: 7ffdf000 EnvironmentPointer: 00000000 ClientId: 0000062c . 00000928 RpcHandle: 00000000 Tls Storage: 00000000 PEB Address: 7ffd6000 LastErrorValue: 0 LastStatusValue: 103 Count Owned Locks: 0 HardErrorMode: 0先查看所有线程的堆栈信息，然后找出比较像出了问题的线程。本次示例只有一个线程，所以肯定是该线程出错。然后显示出错线程的 TEB 信息。 0:000> dps 0x0012a000 0x00130000根据堆栈的位置和大小，显示堆栈的所有内容。根据 Windows 异常处理流程可知，所有没被调试器处理的异常最终都会转到 ntdll!KiUserExceptionDispatcher 函数查找 SEH 异常处理例程来处理异常。所以在显示的堆栈信息中查找 ntdll!KiUserExceptionDispatcher 字符串。 0012fc50 00000000 0012fc54 7c92eafa ntdll!KiUserExceptionDispatcher+0xe 0012fc58 00000000 0012fc5c 0012fc84再根据 KiUserExceptionDispatcher 函数的原型得到本次异常发生时保存的 CONTEXT 结构信息。 ; VOID ; KiUserExceptionDispatcher ( ; IN PEXCEPTION_RECORD ExceptionRecord, ; IN PCONTEXT ContextRecord ; )第二个参数指向 CONTEXT 结构，利用 WinDbg 的 .cxr 命令显示/切换 CONTEXT 结构。 0:000> .cxr 0x0012fc84 eax=00005678 ebx=7ffd6000 ecx=00001234 edx=7c92eb94 esi=011dd664 edi=011dd65c eip=0040100b esp=0012ff50 ebp=00000000 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 Dump01!sum+0xb: 0040100b 8b4508 mov eax,dword ptr [ebp+8] ss:0023:00000008=???????? 0:000> kv *** Stack trace for last set context – .thread/.cxr resets it ChildEBP RetAddr Args to Child 00000000 00000000 00000000 00000000 00000000 Dump01!sum+0xb (CONV: cdecl) [E:\Works\Dump01\Dump01.cpp @ 10]现在已经找到出错地址为 0x0040100b，下面恢复正确的出错堆栈。 0:000> ?? sizeof(ntdll!_CONTEXT) unsigned int 0x2cc 0:000> ? 0x0012fc84 + 0x2cc Evaluate expression: 1245008 = 0012ff50计算可知，出错前的堆栈位置在 0x0012ff50 处。 0:000> ub 0x0040100b L 6 Dump01!sum [E:\Works\Dump01\Dump01.cpp @ 7]: 00401000 55 push ebp 00401001 8bec mov ebp,esp 00401003 53 push ebx 00401004 56 push esi 00401005 57 push edi 00401006 bd00000000 mov ebp,0 0:000> dps 0x0012ff50 L 0x10 0012ff50 011dd65c 0012ff54 011dd664 0012ff58 7ffd6000 0012ff5c 0012ff70 0012ff60 0040103b Dump01!sumstub+0x25 [E:\Works\Dump01\Dump01.cpp @ 19] 0012ff64 00001234 0012ff68 00005678 0012ff6c 00000000 0012ff70 0012ff80 0012ff74 00401074 Dump01!main+0x1f [E:\Works\Dump01\Dump01.cpp @ 30] 0012ff78 00001234 0012ff7c 00005678 0012ff80 0012ffc0 0012ff84 0040117b Dump01!mainCRTStartup+0xb4 0012ff88 00000001 0012ff8c 00520eb0 0:000> r Last set context: eax=00005678 ebx=7ffd6000 ecx=00001234 edx=7c92eb94 esi=011dd664 edi=011dd65c eip=0040100b esp=0012ff50 ebp=00000000 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 Dump01!sum+0xb: 0040100b 8b4508 mov eax,dword ptr [ebp+8] ss:0023:00000008=????????反汇编出错地址前的几条指令，可以知道出错原因是 0x00401006 处的指令导致 ebp 被赋零，所以接下来取参数的指令出错。再根据堆栈信息，出错前往堆栈中压入了 ebx/esi/edi 几个寄存器的值，对比 0x0012ff50 处的堆栈，可知 0x0012ff50 正好是程序出错前的堆栈地址。同时还可以得到保存在堆栈上的 ebp 的值，从而得到正确的出错堆栈。 0:000> kv L = 0x0012ff5c ChildEBP RetAddr Args to Child 0012ff5c 0040103b 00001234 00005678 00000000 Dump01!sum+0xb (CONV: cdecl) 0012ff70 00401074 00001234 00005678 0012ffc0 Dump01!sumstub+0x25 (CONV: cdecl) 0012ff80 0040117b 00000001 00520eb0 00520e20 Dump01!main+0x1f (CONV: cdecl) 0012ffc0 7c816fd7 011dd65c 011dd664 7ffd6000 Dump01!mainCRTStartup+0xb4 0012fff0 00000000 004010c7 00000000 00000000 kernel32!BaseProcessStart+0x23 (FPO: [Non-Fpo])从这个堆栈来看，起始地址从 kernel32!BaseProcessStart 开始，结束地址也正好在出错地址处，应该是正确的出错堆栈。
② 在线等！PS中将图片载入堆栈，PS自动载入一段时间后，所有载入的文件直接没了，好像是被关闭了怎么回事
你试试不要一下载入太多，图片太大，数度慢就会显示不全
③ Photoshop合成星轨 将文件载入堆栈 导入几张就停止了 回到了原始页面 是怎能回事
你下载的是正版的吗如果是破解版请更换Photoshop cs2—–Photoshop cc版本下载 http://blog.sina.com.cn/s/blog_c00bbacb0102uwx2.htmlps2-7破解工具教程让你免费永久使用http://blog.sina.com.cn/s/blog_c00bbacb0102uwkt.html
④ 堆栈问题，数据读入失败
不会VB。不过应该不是你所说的处理太慢的问题。最好检查以下你的程序逻辑
⑤ 调用DLL命令后发现堆栈错误怎么办
现在是更深入地进行探讨的时候了。在对托管代码进行 P/INVOKE 调用时，DLLIMPORTATTRIBUTE 类型扮演着重要的角色。DLLIMPORTATTRIBUTE 的主要作用是给 CLR 指示哪个 DLL 导出您想要调用的函数。相关 DLL 的名称被作为一个构造函数参数传递给 DLLIMPORTATTRIBUTE。如果您无法肯定哪个 DLL 定义了您要使用的 WINDOWS API 函数，PLATFORM SDK 文档将为您提供最好的帮助资源。在 WINDOWS API 函数主题文字临近结尾的位置，SDK 文档指定了 C 应用程序要使用该函数必须链接的 .LIB 文件。在几乎所有的情况下，该 .LIB 文件具有与定义该函数的系统 DLL 文件相同的名称。例如，如果该函数需要 C 应用程序链接到 KERNEL32.LIB，则该函数就定义在 KERNEL32.DLL 中。您可以在 MESSAGEBEEP 中找到有关 MESSAGEBEEP 的 PLATFORM SDK 文档主题。在该主题结尾处，您会注意到它指出库文件是 USER32.LIB；这表明 MESSAGEBEEP 是从 USER32.DLL 中导出的。可选的 DLLIMPORTATTRIBUTE 属性除了指出宿主 DLL 外，DLLIMPORTATTRIBUTE 还包含了一些可选属性，其中四个特别有趣：ENTRYPOINT、CHARSET、SETLASTERROR 和 CALLINGCONVENTION。ENTRYPOINT 在不希望外部托管方法具有与 DLL 导出相同的名称的情况下，可以设置该属性来指示导出的 DLL 函数的入口点名称。当您定义两个调用相同非托管函数的外部方法时，这特别有用。另外，在 WINDOWS 中还可以通过它们的序号值绑定到导出的 DLL 函数。如果您需要这样做，则诸如“#1”或“#129”的 ENTRYPOINT 值指示 DLL 中非托管函数的序号值而不是函数名。CHARSET 对于字符集，并非所有版本的 WINDOWS 都是同样创建的。WINDOWS 9X 系列产品缺少重要的 UNICODE 支持，而 WINDOWS NT 和 WINDOWS CE 系列则一开始就使用 UNICODE。在这些操作系统上运行的 CLR 将UNICODE 用于 STRING 和 CHAR 数据的内部表示。但也不必担心 — 当调用 WINDOWS 9X API 函数时，CLR 会自动进行必要的转换，将其从 UNICODE转换为 ANSI。如果 DLL 函数不以任何方式处理文本，则可以忽略 DLLIMPORTATTRIBUTE 的 CHARSET 属性。然而，当 CHAR 或 STRING 数据是等式的一部分时，应该将 CHARSET 属性设置为 CHARSET.AUTO。这样可以使 CLR 根据宿主 OS 使用适当的字符集。如果没有显式地设置 CHARSET 属性，则其默认值为 CHARSET.ANSI。这个默认值是有缺点的，因为对于在 WINDOWS 2000、WINDOWS XP 和 WINDOWS NT�0�3 上进行的 INTEROP 调用，它会消极地影响文本参数封送处理的性能。应该显式地选择 CHARSET.ANSI 或 CHARSET.UNICODE 的 CHARSET 值而不是使用 CHARSET.AUTO 的唯一情况是：您显式地指定了一个导出函数，而该函数特定于这两种 WIN32 OS 中的某一种。READDIRECTORYCHANGESW API 函数就是这样的一个例子，它只存在于基于 WINDOWS NT 的操作系统中，并且只支持 UNICODE；在这种情况下，您应该显式地使用 CHARSET.UNICODE。有时，WINDOWS API 是否有字符集关系并不明显。一种决不会有错的确认方法是在 PLATFORM SDK 中检查该函数的 C 语言头文件。（如果您无法肯定要看哪个头文件，则可以查看 PLATFORM SDK 文档中列出的每个 API 函数的头文件。）如果您发现该 API 函数确实定义为一个映射到以 A 或 W 结尾的函数名的宏，则字符集与您尝试调用的函数有关系。WINDOWS API 函数的一个例子是在 WINUSER.H 中声明的 GETMESSAGE API，您也许会惊讶地发现它有 A 和 W 两种版本。SETLASTERROR 错误处理非常重要，但在编程时经常被遗忘。当您进行 P/INVOKE 调用时，也会面临其他的挑战 — 处理托管代码中 WINDOWS API 错误处理和异常之间的区别。 可以给您一点建议。如果您正在使用 P/INVOKE 调用 WINDOWS API 函数，而对于该函数，您使用 GETLASTERROR 来查找扩展的错误信息，则应该在外部方法的 DLLIMPORTATTRIBUTE 中将 SETLASTERROR 属性设置为 TRUE。这适用于大多数外部方法。这会导致 CLR 在每次调用外部方法之后缓存由 API 函数设置的错误。然后，在包装方法中，可以通过调用类库的 SYSTEM.RUNTIME.INTEROPSERVICES.MARSHAL 类型中定义的 MARSHAL.GETLASTWIN32ERROR 方法来获取缓存的错误值。 的建议是检查这些期望来自 API 函数的错误值，并为这些值引发一个可感知的异常。对于其他所有失败情况（包括根本就没意料到的失败情况），则引发在 SYSTEM.COMPONENTMODEL 命名空间中定义的 WIN32EXCEPTION，并将 MARSHAL.GETLASTWIN32ERROR 返回的值传递给它。如果您回头看一下图 1 中的代码，您会看到 在 EXTERN MESSAGEBEEP 方法的公共包装中就采用了这种方法。CALLINGCONVENTION 将在此介绍的最后也可能是最不重要的一个 DLLIMPORTATTRIBUTE 属性是 CALLINGCONVENTION。通过此属性，可以给 CLR 指示应该将哪种函数调用约定用于堆栈中的参数。CALLINGCONVENTION.WINAPI 的默认值是最好的选择，它在大多数情况下都可行。然而，如果该调用不起作用，则可以检查 PLATFORM SDK 中的声明头文件，看看您调用的 API 函数是否是一个不符合调用约定标准的异常 API。通常，本机函数（例如 WINDOWS API 函数或 C- 运行时 DLL 函数）的调用约定描述了如何将参数推入线程堆栈或从线程堆栈中清除。大多数 WINDOWS API 函数都是首先将函数的最后一个参数推入堆栈，然后由被调用的函数负责清理该堆栈。相反，许多 C-运行时 DLL 函数都被定义为按照方法参数在方法签名中出现的顺序将其推入堆栈，将堆栈清理工作交给调用者。幸运的是，要让 P/INVOKE 调用工作只需要让外围设备理解调用约定即可。通常，从默认值 CALLINGCONVENTION.WINAPI 开始是最好的选择。然后，在 C 运行时 DLL 函数和少数函数中，可能需要将约定更改为 CALLINGCONVENTION.CDECL。
⑥ 将文件载入堆栈是什么，堆栈是什么
堆栈都是一种数据项按序排列的数据结构，只能在一端(称为栈顶(top))对数据项进行插入和删除。要点：堆：顺序随意栈：后进先出
⑦ photoshop将文件载入堆栈有什么作用
图像应具有相同的尺寸和极其相似的内容，将他们载入堆栈，可以使它们与组中的其它图像套准或对齐。 消除不想要的部份
⑧ 使用Photoshop出现~ 错误22：windows没有构造函数
重装PS，我遇见了这个问题，最后自己解决，看了网上的方法，最后一想，原来自己的PS软件是复制过来的绿色版，根本没有安装过程，所以造成了函数问题，结果我重装了一遍PS，现在问题解决了。
⑨ PS CS5 我想导入图片包做GIF 但是我选择文件-脚本-将文件载入堆栈 显示错误代码22 什么函数构造错误
Ps cs 5是这么多ps版本里，最方便导入gif的，只需要打开“窗口”-“动画”，然后将GIF拖入PS中即可编辑。我现在就是用ps cs5，并且时常处理gif，请下载安装版吧。
