1.10个用于C＃.NET开发的基本调试工具
2.Windows未成功关闭。如果这是由于系统无响应，或者是为保护数据而关闭系统...这怎么办？
3.Microsoft visual c++弹窗？

10个用于C＃.NET开发的基本调试工具

       在调试软件时，正确选择工具至关重要，这能帮助你从错误信息中提取有用信息，从而找到问题根源并解决它们。array list 源码本文为你介绍款用于C# .NET开发的基本调试工具，它们能够帮助你解决各种难题。

       首选工具无疑是Visual Studio，它作为世界顶级的IDE之一，提供了丰富的调试功能，如工具窗口、异常选项、工具提示等。根据StackOverflow 年的调查，它成为了所有开发人员第二受欢迎的IDE。

       此外，dnSpy 和 dotPeek 是两款强大的调试工具。dnSpy 作为反编译器，允许你调试 .NET 程序，无需依赖符号或源代码。而 dotPeek 则是 JetBrains 的免费反编译器，它在性能分析方面表现出色，能够记录应用运行情况并提供详细分析报告。

       dotTrace 是 JetBrains 的另一款出色工具，专注于性能分析，能帮助你深入了解应用的性能瓶颈，提供详细的方法执行时间和资源消耗分析。

       SciTech's .NET Memory Profiler 则专注于内存管理，帮助你识别内存泄露和性能问题，确保应用程序高效运行。

       OzCode 是 Visual Studio 的扩展，专门用于交互式调试，提供了可视化功能、LINQ调试、数据提示以及时间穿梭功能，让你更轻松地跟踪代码执行流程。

       SysInternals Suite 集合了一系列用于故障排除和监控的实用程序，其中 Process Explorer 和 ProcMon 提供了深入的甘特图 vba源码进程和事件监控，而 ProcDump 则用于捕捉崩溃转储，帮助你快速定位问题。

       Performance Monitor（PerfMon）内置在 Windows 系统中，用于监控系统和进程的性能指标，帮助你跟踪关键性能参数。

       PerfView 是一个基于 Windows 事件跟踪（ETW）的通用分析工具，能够提供详细的系统和进程性能分析，帮助你深入了解系统行为。

       Fiddler 是一个免费的 HTTP 代理服务器，用于调试网络请求，提供详细的请求和响应信息。

       WinDbg 是一个命令行调试器，曾经是 Windows 的主要调试工具，但随着 Visual Studio 的发展，它的重要性逐渐降低。对于当前的 .NET 开发，Visual Studio 提供了足够强大的功能。

       以上工具各自擅长不同的方面，了解并熟练使用它们将极大地提升你的开发效率。在选择时，可以根据具体需求考虑同类工具的替代方案，如使用 dotMemory 替换内存分析器，或者 RedGate 的性能分析器来代替 dotTrace。

Windows未成功关闭。如果这是由于系统无响应，或者是为保护数据而关闭系统...这怎么办？

先关机，然后打开主机箱，把硬盘的电源线和数据线拔下来，然后过2分钟再插上，重新开机试试。然后用下述方法修复系统：

开机不断点击F8键，进入系统操作选单（如果是Win8,Win8.1,Win系统，在看见开机画面后长按电源键关机，短时间内重复三次左右可以进入WinRE { Windows 恢复环境}，但有的源码资本 火球用户可能需要直接断开电源。这样开机后应该能出现高级恢复的界面了，在高级回复界面，选择进入安全模式。

第一，由软：尝试修复操作系统：

1、如果有外接设备：如U盘、USB移动硬盘，或者读卡器里面有存储卡，请去除后再试

2、去除加装非标配部件，如内存、硬盘等，建议您联系操作者将添加的部件去除后再试

3、进入电脑BIOS并查看?BIOS中是否还能识别硬盘，同时选择“Load Optimal Defaults”或“Optimized Defaults”选项恢复BIOS默认设置后测试

4、开机不断点击F8键，进入系统操作选单（如果是Win8,Win8.1,Win系统，在看见开机画面后长按电源键关机，短时间内重复三次左右可以进入WinRE { Windows 恢复环境}，但有的用户可能需要直接断开电源。这样开机后应该能出现高级恢复的界面了），选“最后一次正确配置”，重启电脑，看能否解决。

5、开机不断点击F8键，进入系统操作选单（如果是Win8,Win8.1,Win系统，在看见开机画面后长按电源键关机，短时间内重复三次左右可以进入WinRE { Windows 恢复环境}，但有的用户可能需要直接断开电源。这样开机后应该能出现高级恢复的界面了），然后寻找“安全模式”，并进入“安全模式”，如能成功进入，依次单击“开始”→“所有程序”→“附件”→“系统工具”→“系统还原”，出现“系统还原对话框”，选择“恢复我的计算机到一个较早的时间”。 这样可以用Windows系统自带的baocms源码7.2系统还原功能，还原到以前能正常开机的时候一个还原点。（如果有的话）

6、用系统安装光盘或者系统安装U盘，放入光驱或者插入USB接口，重启电脑，进入光盘安装系统状态或者进入U盘安装系统状态，等到启动界面闪过后，不要选安装系统，而是选修复系统，对目前系统进行修复（可能会运行很长时间，2-4小时都可能），耐心等待修复完成，看看是否能解决问题。（本文结尾，详述了：U盘设置为第一启动顺位设备的方法）

7、不稳定的硬件设备，设备驱动程序过期，以及第三方程序干扰也会造成黑屏或者蓝屏，建议先进入安全模式，自行评是否原因为驱动程序过期或者三方程序干扰。此时，请您到电脑制造商网站上下载最近的BIOS, 声卡或显卡等所有可用驱动进行更新来解决问题。

如以上7个方法都无效，只能重装系统。

二、到硬：看看是否是硬件的问题：

1，主板钮扣电池没电了，这时保存时间等将在关机断电后，信息将无法保存。换一块新电池试一下。

2，主板BIOS出错，一些主板有防入侵机制。如果最近有跟换过配件，也可能是主板BIOS的错误引起。解决的办法是开机按DEL键（或者开机屏幕提示的键），进入主板BIOS，初始化BIOS设置信息，view源码分析通常按F9可以恢复出厂默认设置，再按F保存退出重启电脑。

3，CMOS（BIOS）设置错误,主要是关于软件的设置的选项出现了问题。可以在开机后入Bios 进行设置。

这时可以查看一下自己的机器有没有软驱、光盘或其它附设[如:显卡]，如果没有这些硬件，而电脑却设置了这些，可以试着把这些选项关掉或设为Disabled.

[注:CD/DVD/CD-RW DRIVE：可读写的光驱 CD-ROW DEVICE：只读光驱 Diskette Drive：软盘驱动器 Floppy Floppy Device：软驱设备]

4，CMOS（BIOS）原来设置的部分与现在的硬件有冲突的部分.可以前将CMOS（BIOS）进行放电,在主板钮扣电池旁边有一个cmos 的三针跳线,而一般其中的两个针是联在一起的,这时可以在关机断电的情况下,将跳帽拔出,用跳帽将两个针联在一起进行放电[此过程一般4秒左右],而后再恢复到样子.或是将钮扣电池拔下,反过来装进去等待5-6秒左右进行放电,而后恢复到原来的样子，在开机后可以进入CMOS（BIOS）恢复其默认设置即可。

5，是否是未装显卡驱动，或者显卡驱动损坏，解决办法、；更新显卡驱动程序，用电脑自带的驱动程序光盘或者去显卡官网下载最新驱动程序，更新显卡驱动，也可以去驱动之家网站，下载驱动精灵最新版，升级显卡驱动； 

6，硬盘检测没有过去，可以试着给硬盘换下数据线，如果没有线也可以试着把数据线两头对换一下，再换个主板上的接口。 

7，如果硬盘换过数据线后还是无效，也可以先试着拔掉硬盘的数据线不接，然后开机测试。看是否还会卡在LOGO屏这里，如果能跨过LOGO界面，估计就是硬盘故障了，进入BIOS寻找硬盘或者进入PE系统检测硬盘健康度，如果硬盘读不到或者检测硬盘证明已经损坏，就只有更换硬盘了。

8，硬件接触不良 主要表现在显卡或内存条与主板接触不良。这时可以把显卡或者内存条拔掉，把显卡或者内存条拔掉不影响开机时进入cmos界面.这时如果进入这个界面时,没出CMOS（BIOS）setting wrong,就可以断定是显卡或者内存条的问题. 可以先用好一点的橡皮对其与主板接触的部分进行擦拭,内存也是用橡皮擦拭.

9，硬盘与光驱 不同内存条之间有冲突，此时可以进行逐一排查，可以先把光驱的电源线与数据排线拔掉，而后试着分别只用一条内存进行排查。

，检查机器是否有外接设备连接，U盘、移动硬盘等等外接设备可能插在电脑USB口上忘记拔掉了，造成主板自检卡主通过不了。解决的办法就是拔出多余的外接设备，再重启电脑。

，检查一下键盘和鼠标是否接反。这里指的是PS/2接口的键盘鼠标，很多人大意，把键盘和鼠标的接口插反了，造成开机电脑的自检错误以至于卡屏。解决的办法，先关机，重新接过键盘鼠标，通常紫色的接口为键盘，绿色接口为鼠标。 

，主板本身可能出了问题.可以先检查一下是否主板电池电路断路，或者是否有电容爆掉,如果是的话,自己焊接和更换或者找电脑维修商帮你焊接和更换一个同规格电容的即可。如果是主板坏了，那只有去买个新的换上啦。

，机箱不清洁.CPU风扇积灰太多不能正常运行,造成CPU温度过高，用毛刷、电吹风将机箱内壁、CPU风扇、显卡风扇、主板上的积灰都清理一遍。

Microsoft visual c++弹窗？

       适用于 Linux 的 Windows 子系统中的 Visual Studio Code 服务器使用本地 WebSocket WebSocket 连接与远程 WSL 扩展进行通信。网站中的 JavaScript 可以连接到该服务器并在目标系统上执行任意命令。目前该漏洞被命名为CVE--。

       这些漏洞可以被用于：

       本地 WebSocket 服务器正在监控所有接口。如果允许通过 Windows 防火墙，外部应用程序可能会连接到此服务器。

       本地 WebSocket 服务器不检查 WebSocket 握手中的 Origin 标头或具有任何身份验证模式。浏览器中的 JavaScript 可以连接到该服务器。即使服务器正在监控本地主机，也是如此。

       我们可以在特定端口上生成一个Node Inspector示例，它还监控所有接口。外部应用程序可以连接到它。

       如果外部应用程序或本地网站可以连接到这些服务器中的任何一个，它们就可以在目标计算机上运行任意代码。

       Visual Studio Code 库是不断更新的。我将使用一个特定的提交 (bbcaf3db8bb8adf0ccfa)。

       $ git clone /microsoft/vscode $ git reset --hard bbcaf3db8bb8adf0ccfa

       我们可以使用 Code (lol) 来导航源代码。事实上，我已经在 WSL 中为这个漏洞创建了具有相同扩展名的概念验证。

       Visual Studio Code在 WSL 内以服务器模式运行，并与 Windows 上的代码示例对话（我称之为代码客户端）。这使我们可以在 WSL 中编辑文件和运行应用程序，而不需要运行其中的所有内容。

       远程开发架构

       可以通过 SSH 和容器在远程计算机上进行远程开发。GitHub Codespaces 使用相同的技术（很可能通过容器）。

       在 Windows 上使用它的方法：

       1.打开一个WSL终端示例，在Windows上的代码中应该可以看到远程WSL扩展；

       2.在 WSL 中运行code /path/to/something；

       3.如果未安装代码服务器或已过时，则会下载它；

       4.VS Code 在 Windows 上运行；

       5.你可能会收到一个 Windows 防火墙弹出窗口，用于执行如下所示的可执行文件：

       服务器的防火墙对话框

       这个防火墙对话框是我执行失败的原因。出现该对话框是因为 VS Code 服务器想要监控所有接口。

       从我信任的Process Monitor开始：

       1.运行进程监控器；

       2.在WSL中运行code .；

       3.Tools > Process Tree；

       4.我运行代码（例如，Windows Terminal.exe）的终端示例中运行Add process and children to Include filte。

       Procmon 的进程树

       经过一番挖掘，我发现了 VSCODE_WSL_DEBUG_INFO 环境变量。我只是在 WSL 中将 export VSCODE_WSL_DEBUG_INFO=true 添加到 ~/.profile 。运行服务器后我们会得到额外的信息。

       VSCODE_WSL_DEBUG_INFO=true

       输出被清理。

       检查命令行参数。

       可以看到出现了WebSocket词汇。

       运行 Wir.shark 并捕获loopback接口上的流量。然后我再次在 WSL 中运行代码。这次可以看到两个 WebSocket 握手。

       在 Wireshark 中捕获的 WebSocket 连接

       该运行中的服务器端口是，我们也可以从日志中看到。在 Windows 上的代码客户端中打开命令面板 (ctrl+shift+p) 并运行 > Remote-WSL: Show Log。

       远程 WSL：显示日志

       最后一行有端口：在 mon/ipc.net.ts 中看到协议的源代码。

       来自服务器的第一条消息是 KeepAlive 消息。

       在协议定义中，我们可以看到不同的消息类型。

       在 /src/vs/platform/remote/common/remoteAgentConnection.ts 中，它在代码的其他部分被称为 OKMessage 和heartbeat。

       客户端在/src/vs/platform/remote/common/remoteAgentConnection.ts的connectToRemoteExtensionHostAgent中处理此问题。客户端(Windows上的代码)发送这个包，它是一个KeepAlive和一个单独的认证消息。

       最初，我认为长度字段是 个字节而不是 4 个字节，因为其余的字节总是空的。然后我意识到只有常规消息使用消息 ID 和 ACK 字段，而且我只看到了不规则的握手消息。

       在修复之前，没有勾选此选项。

       注意：在 -- 更新之前（commit bbcaf3db8bb8adf0ccfa）客户端没有发送数据。但是，使用此提交，我们仍然可以在没有此密钥的情况下发送消息并且它会起作用。这是我们给服务器签名的内容，以检查连接到正确的服务器。

       服务器响应一个签名请求。

       另一个 JSON 对象：

       服务器已经签名了我们在前一条消息中发送的数据，并用它自己的数据请求进行了响应。

       客户端验证签名的数据，以检查它是否是受支持的服务器。当创建我们的客户端时，可以简单地跳过。

       使用options.signService.validate 方法，然后就会得到/src/vs/platform/sign/node/signService.ts。

       vsda 是一个用 C++ 编写的 Node 原生插件，将 Node 原生插件视为共享库或 DLL。该插件位于 /microsoft/vsda 的私有存储库中，根据mit}/node_modules/vsda/build/Release/vsda.node。

       我找到了/kieferrm/vsda-example，并通过一些实验找到了如何使用它创建和签名消息。

       1.用msg1 = validator.createNewMessage("")创建一个新消息，输入至少4个字符。

       2.使用signed1 = signer.sign(msg1)进行签名。

       3.使用 validator.validate(signed1) 对其进行验证，响应为“ok”。

       需要注意的是，如果你创建了新消息，则无法再验证旧消息。在源代码中，每条消息都有自己的验证器。

       Linux 版本有符号，大小约为 KB。把它放到 IDA/Ghidra 中，应该就可以开始了。

       我花了一些时间，想出了这个伪代码。可能不太正确，但可以让你大致了解此签名的工作原理。

       1.用当前时间 + 2*(msg[0]) 初始化 srand，它只会创建 0 到 9（含）之间的随机数；

       2.从许可证数组中附加两个随机字符；

       3.从 salt 数组中附加一个随机字符；

       4.SHA；

       5.Base；

       6.；

       7.Profit。

       仅从许可证数组中选择前 个位置的字符，它总是 rand() % ，但salt 数组翻了一番。

       许可证数组的字符串如下所示：

       salt 数组的前 个字节（查找 Handshake::CHandshakeImpl::s_saltArray）是：

       我从来没有真正检查过我的分析是否正确，不过这无关紧要，知道如何使用插件签名消息，这就足够了。

       接下来，客户端需要签名来自服务器的数据并将其发送回来，以显示它是一个“合法”的代码客户端。

       服务器响应如下：

       客户端发送了如下消息：

       提交应该匹配服务器的提交哈希。这不是秘密。这可能是最后一个稳定版本提交（或最后几个之一）。这只是检查客户端和服务器是否在同一版本上。它也可以在 /parsiya/code-wsl-rce /parsiya/Parsia-Code/tree/master/code-wsl-rce

       模拟代码客户端

       创建客户端并使用协议连接到服务器的代码位于 VS Code GitHub 存储库中，这需要大量的复制/粘贴和解析，我只花了几个小时。

       如果要创建一个快速的概念验证，应该满足一些假设：

       1.找到本地的 WebSocket 端口；

       2.从外部连接到Node Inspector示例；

       查找本地 WebSocket 端口并不难，从浏览器扫描本地服务器并不是什么新鲜事。服务器也可以从外部使用，因此我们不受那里的浏览器约束。

       Chrome 限制不起作用，因为 WebSocket 服务器需要一个网络服务器来处理握手。我也很好奇 WebSocket 节流是 Chrome 特定的保护还是 Chromium 的一部分。

       有趣的是，Chrome 浏览器有一个保护机制，可以防止恶意行为者暴力破解 WebSocket 端口，它在第 次尝试后开始节流。不幸的是，这种保护很容易被绕过，因为扩展的 HTTP 和 WebSocket 服务器都在同一个端口上启动。这可用于通过向 img 标签添加 onload 处理程序来检查特定本地主机端口上的是否存在来强制所有可能的本地端口。

       也就是说，这是一个开发环境，用户可能整天都在 WSL 中开发并且从不关闭他们的浏览器选项卡，因此如果他们打开我们的网站，我们就有可能找到它。

       连接到Node Inspector示例是另一回事，我们无法从浏览器执行此操作，因此我们需要我们的服务器可以访问受害者的计算机。

       第二种利用方法（模拟代码客户端）没有这些限制，因为浏览器可以与本地服务器通信并执行所有操作。它只需要我们对协议进行逆向工程并找出要发送的正确消息。

       当你收到 WebSocket 升级请求时，请根据许可名单检查 Origin 标头。代码客户端在该标头中发送 vscode-file://vscode-app，以便我们可以使用它来操作。

       参考及来源：/blog/---rce-in-visual-studio-codes-remote-wsl-for-fun-and-negative-profit/