小编Tho*_*ler的帖子

我有这个代码:

var list = new List<int>();
for(int i=0;i<10;i++) list.Add(i); 
for(int i=0;i<10;i++)
{
     ThreadPool.QueueUserWorkItem(
         new WaitCallback(x => {
             Console.WriteLine(x);  
         }), list[i]);
} 

我想知道所有线程池线程什么时候完成他们的工作.我该怎么做？

我可能做错了什么,但我无法想出这个.

我有一个简单的崩溃minidump,在Windows上生成.如果我在visual studio中打开转储,它会毫无问题地加载并显示崩溃线.但是我无法在minidump_stackwalker中表达它.

我创建了一个符号存储库文件夹,里面有:symbols/myapplication.pdb/67892B042C8F4CCFAA6BE53445F9B2141/myapplication.sym以及应用程序使用的所有:symbols/wkernel32.pdb/XXXXXX/wkernel32.sym等.

当我调用"minidump_stackwalk mycrash.dmp symbols"时,stderr显示simple_symbol_supplier正确找到所有符号,并加载它们.但是,输出保持为堆栈,其中没有任何符号.

我还尝试在linux和MacOSX上编译并运行minidump_stackwalk,但结果是一样的.

我究竟做错了什么？

stackwalk的stderr输出如下所示:

2014-05-08 16:44:48: minidump_processor.cc:235: INFO: Processing minidump in file 604c29d0-318a-4321-9e40-b0198085c17d.dmp
2014-05-08 16:44:48: minidump.cc:3258: INFO: Minidump opened minidump 604c29d0-318a-4321-9e40-b0198085c17d.dmp on fd 3
2014-05-08 16:44:48: minidump.cc:3303: INFO: Minidump not byte-swapping minidump
2014-05-08 16:44:48: minidump.cc:1726: ERROR: MinidumpModule could not determine debug_file for C:\Windows\winsxs\x86_microsoft.vc90.mfcloc_1fc8b3b9a1e18e3b_9.0.30729.6161_none_49768ef57548175e\MFC90ENU.DLL
2014-05-08 16:44:48: minidump.cc:1794: ERROR: MinidumpModule could not determine debug_identifier for C:\Windows\winsxs\x86_microsoft.vc90.mfcloc_1fc8b3b9a1e18e3b_9.0.30729.6161_none_49768ef57548175e\MFC90ENU.DLL
2014-05-08 16:44:48: minidump_processor.cc:103: INFO: Minidump 604c29d0-318a-4321-9e40-b0198085c17d.dmp has CPU info, OS info, Breakpad info, exception, module list, thread list, dump thread, …

我捕获了在64位Windows操作系统上运行的32位.NET应用程序的故障转储.在分析过程中,有人发现我有一个64位转储并告诉我由于错误的位数而无法分析这个转储.

使用Windows任务管理器创建转储时,我不知道我做错了什么.这始终适用于32位操作系统.

我怎样才能为.NET提供良好的转储,尤其是正确的位数？

我试图从procmon解码以下调用堆栈行:

29  System.Management.Automation.ni.dll System.Management.Automation.ni.dll + 0x897a0a  0x7fee2ae7a0a   C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a86698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll

正如您所看到的,其中有一个NGEN-ed程序集:System.Management.Automation.ni.dll.我使用ngen createpdb为它创建了一个pdb文件:

PS> ngen createpdb c:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a86698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll c:\symbols\ngen

Successfully generated PDB for native assembly 'c:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a8698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll'.
PDB generated in directory c:\symbols\ngen\System.Management.Automation.ni.pdb a86698074f28597f1fc5ceabfed6fed61\

_NT_SYMBOL_PATH变量中的符号路径是:

SRV*C:\symbols\ngen*;SRV*C:\symbols\dbg*http://referencesource.microsoft.com/symbols;SRV*C:\symbols\dbg*http://msdl.microsoft

.COM /下载/符号

但我仍然可以看到没有为程序集加载新生成的符号文件:

PS a86698074f28597f1fc5ceabfed6fed6> dbh -n .\System.Management.Automation.ni.dll
verbose mode on.
DBGHELP: No header for .\System.Management.Automation.ni.dll.  Searching for image on disk
DBGHELP: C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\a86698074f28597f1fc5ceabfed6fed6\System.Management.Automation.ni.dll - OK
SYMSRV:  C:\symbols\ngen\System.Management.Automation.pdb\6B8B8F14D0564CB893B6E84B43CAE67B1\System.Management.Automation.pdb - file not found
SYMSRV:  C:\tools\diag\Debugging Tools for Windows\x64\sym\System.Management.Automation.pdb\6B8B8F14D0564CB893B6E84B43CAE67B1\System.Management.Automation.pdb - file not found
SYMSRV:  C:\symbols\ngen\System.Management.Automation.pdb\6B8B8F14D0564CB893B6E84B43CAE67B1\System.Management.Automation.pdb not found
SYMSRV: …

我有以下代码,它失败了,因为它无法从磁盘读取文件.图像总是如此None.

# -*- coding: utf-8 -*-
import cv2
import numpy

bgrImage = cv2.imread(u'D:\\ö\\handschuh.jpg')

注意:我的文件已经保存为带有BOM的UTF-8.我用Notepad ++验证了.

在Process Monitor中,我看到Python正在从错误的路径访问该文件:

我读过:

• 打开带有unicode文件名的文件,该文件与open()函数有关,与OpenCV无关.
• 如何使用Python读取图像文件,但这与Unicode问题无关.

在.NET中,每个对象有8个字节的开销.4个字节是指向对象类型的指针.其他4个字节,称为对象标头,用于什么？

注意:问题在2010年被提出并且是32位特定的.开销是依赖于位的:"对象类型"(方法表)的1个指针大小和对象标题的1个指针大小.因此,32位为2*4字节,64位应用为2*8字节.

我最近有一个不会加载的XML.错误消息是

十六进制值0x00是无效字符

通过LinqPad中的最少代码(C#语句)收到:

var xmlDocument = new XmlDocument();
xmlDocument.Load(@"C:\Users\Thomas\AppData\Local\Temp\tmp485D.tmp");

我使用十六进制编辑器浏览了XML但找不到0x00字符.我把XML最小化了

<?xml version="1.0" encoding="UTF-8"?>
<x>
</x>

在我的十六进制编辑器中,它显示为

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  FF FE 3C 00 3F 00 78 00 6D 00 6C 00 20 00 76 00  ÿþ<.?.x.m.l. .v.
00000010  65 00 72 00 73 00 69 00 6F 00 6E 00 3D 00 22 00  e.r.s.i.o.n.=.".
00000020  31 00 2E 00 30 00 22 00 20 …

虽然我认为应该有一个继承注释的一般规则,但我特别感兴趣的是让FindBugs识别我的规则,所以这个问题是特定于FindBugs的.

AFAIK,JavaDoc注释来自接口,在实现时被忽略.这个概念是否也适用于像@Nonnull(或@NotNull)这样的注释？

给定@Override注释,至少可以添加在接口处不存在的附加注释.

在下列情况下会发生什么？FindBugs会识别所有这些吗？关于清洁代码,哪一个是首选的？

1. 接口@Nonnull,实现@Override
2. 接口@Nonnull,实现@Override,@Nonnull
3. 接口没有注释,Implementation @Override,@ Nonnull`

当我看到这个对话框弹出时,我感到很震惊,因为我以为我是加密病毒的受害者:

使用Process Explorer查看哪个进程打开了对话框,我发现efsui.exe并验证了签名,以确保它是Microsoft的官方产品.

接下来,我搜索了这个,我找到了cipher /u在磁盘上查找加密文件的命令.结果是

C:\Windows\system32>cipher /u
C:\Users\XXX\Documents\Visual Studio 2015\Backup Files\Form1.Designer.vb\~AutoRecover.Form1.Designer.vb.sln: Encryption updated.

在资源管理器中打开文件夹时确认了这一点.

我正在使用Visual Studio很长一段时间,但这是我第一次打开VB Form.

Visual Studio加密文件是否常见？它只发生在VB上,还是因为安装了其他的VS更新？如何关闭该功能？

我试过了:

• 在Visual Studio的快速查找框中输入"encrypt"和"encryption".
• 找到这样一个关于可移动驱动器的答案,但我的驱动器是C:并且不可移动.

我在最新的Windows 10上将x64 cdb添加Windows Kits 10到了MSVC 2015 64bitKit中的调试器设置qtcreator 4.1.0.

但是当我为我的应用程序运行调试器时,调试器似乎开始很慢.即使是第一次运行hello world也需要3分钟才能启动和完成,与我自己的应用程序相同.在第一次调试开始之后,有时它会快一点(不到1分钟),但仍然没有linux那么快,几乎立即显示并完成程序的运行.

表明:

starting debugger cdbengine for abi "x86-windows-msvc2015-pe-64bit"

需很长时间.

关于如何解决这个缓慢启动的任何想法？