>>任务管理器不可能让你清楚地了解>>正在发生什么。别忘了Windows性能监视器。自NT以来内置于每个Windows系统中，您可以从那里获得更多信息。记录和在进程甚至线程基础上看到峰值内存使用量，句柄数量等。为了识别与句柄泄漏相结合的内存泄漏，它在很久以前帮助了我们（在Windows环境中更糟糕...... ）当然它不会取代调试器来查找代码中的真正原因，但是它可以为您提供有关症状的更详细的视图.BMartin 以上来自于谷歌翻译 以下为原文> > the task manager can't possibly give you a clear idea of> > what's going on.Don't forget about the Windows Performance Monitor. Built into every Windows system since NT you can obtain even more information from there. Log & see Peak memory usage, handle counts, etc. on process or even thread base.It helped us a lot some time ago in order to identify memory leakages which were combined with handle leakage as well (which is even worse in Windows environment...)Of course it does not supersede a debugger to find the real cause in code, but it can give you a some more detailed view on the symptom.brMartin
2019-08-29 06:08
带有汽车显示器/开关的ActiveX工具箱你好，有没有人知道一个好的ActiveX汽车工具箱，例如转速表，温度显示器，条形图，适用于VEE？最好的问候拉尔夫 以上来自于谷歌翻译 以下为原文ActiveX toolbox with automotive displays / switchesHello,does anybody know a good ActiveX automotive toolbox with e.g tachometer, temperature displays, bar graphs that works well with VEE? Best regardsRalf---You are currently subscribed to vrf
2019-08-28 09:03
当我试图写我的I2C EEPROM时，我遇到了一个总线冲突。我使用的MCC生成的库为400千赫，并具有2.2K拉电阻。我很难找到引起它的原因。它似乎与电信号无关，因为我能够发送字节，并且eeprom根据我的逻辑分析器发送第9位的ACK。我搞不清楚的是什么时候发生公交车碰撞（针脚的什么情况有问题，可能是因为SDA在末尾保持低位）。这是代码，Fcy是60MHz。我尝试了CE419，但它挂起等待一个从未发生过的中断。如果SDA保持在低位，那么如何修复它（或者至少判断它是否由于某种原因被dspic（可能）或24AA64T保持在低位）。如您所见，它在消息开始之前被拉高，但这可能不意味着很多。在错误发生之前，我还附上了逻辑分析器的输出： 以上来自于百度翻译 以下为原文 I'm getting a bus collision when trying to write to my i2c eeprom.I'm using the MCC generated library for 400kHz and have 2.2k pull up resistors.I'm having trouble tracking down what is causing it.It doesn't seem to be related to the electrical signals, as i am able to send bytes and the eeprom sends the ACK for the 9th bit according to my logic analyzer.The part i can't figure out is when the bus collision is happening (ie what condition on the pins is the problem, maybe because SDA stays low at the end).Here's the code, Fcy is 60MHz.I tried CE419, but it hangs waiting for an interrupt that never occurs.If it is the SDA staying low, how does one fix that (or at least tell whether it is being held low by the dspic (probably) or the 24AA64T for some reason.As you can see, it is pulled high prior to the start of the message, but that may not mean much. #include #include "mcc_generated_files/mcc.h"#define SLAVE_I2C_GENERIC_RETRY_MAX 100#define SLAVE_I2C_GENERIC_DEVICE_TIMEOUT 500 // define slave timeout int main(void){ // initialize the device SYSTEM_Initialize(); // When using interrupts, you need to set the Global Interrupt Enable bits // Use the following macros to: // Enable the Global Interrupts //INTERRUPT_GlobalEnable(); // Disable the Global Interrupts //INTERRUPT_GlobalDisable(); uint8_t slaveDeviceAddress = 0b1010000; //control code 1010 address 000, shift left 1 for r/w bit uint16_t dataAddress; uint8_t sourceData[16] = { 0xA0, 0xA1, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7, 0xA8, 0xA9, 0xAA, 0xAB, 0xAC, 0xAD, 0xAE, 0xAF }; uint8_t *pData; uint16_t nCount; uint8_t writeBuffer[3]; uint8_t *pD; uint16_t counter, timeOut, slaveTimeOut; I2C1_MESSAGE_STATUS status = I2C1_MESSAGE_PENDING; dataAddress = 0x10; // starting EEPROM address pD = sourceData; // initialize the source of the data nCount = 16; // number of bytes to write for (counter = 0; counter < nCount; counter++){writeBuffer[0] = (dataAddress >> 8); // high addresswriteBuffer[1] = (uint8_t)(dataAddress); // low low addresswriteBuffer[2] = *pD++;timeOut = 0;slaveTimeOut = 0;while(status != I2C1_MESSAGE_FAIL){ I2C1_MasterWrite( writeBuffer, 3, slaveDeviceAddress, &status); // write one byte to EEPROM (3 is the number of bytes to write)while(status == I2C1_MESSAGE_PENDING) { // wait for the message to be sent or status has changed. if (slaveTimeOut == SLAVE_I2C_GENERIC_DEVICE_TIMEOUT)break; elseslaveTimeOut++;} if (slaveTimeOut == SLAVE_I2C_GENERIC_DEVICE_TIMEOUT){ break;}if (status == I2C1_MESSAGE_COMPLETE){ break;}if (timeOut == SLAVE_I2C_GENERIC_RETRY_MAX){ // check for max retry and skip this byte break;}else{ timeOut++;}}if (status == I2C1_MESSAGE_FAIL){break; //
2019-05-31 08:46
) - memory address bumped up by 1 internallyDmaRegs.CH1.SRC_BURST_STEP = 1;// DRR2 must be read first &
2019-04-09 10:27
嗨，我正试图解决最后几个遗留问题与我的设计，我有几个问题：1。我在呼吸压力模拟输入和比较器使用的一些参考电压之间得到了许多模拟交叉耦合。如果我尝试使用不同的模拟输入，那么设计将无法路由。你有什么建议或建议，如何解决这个问题？2。模拟多路复用器的当前限值是多少？我想用一个放电电阻器代替其他DAC，这样我就可以释放它来增加分辨率。三。我试图使用抖动模块来增加DAC分辨率，但是我正在运行共享总线问题（见之前从未得到回复的帖子），有没有办法做到这一点？谢谢，-迈克 以上来自于百度翻译 以下为原文Hi, I'm trying to fix the last few remaining problems with my design, and I have a few questions: 1.I'm getting a lot of analog cross-coupling between the breath pressure analog input and some of the reference voltages used by the comparators.If I try to use a different analog input , then the design will fail to route.Do you have any advice or suggestions on how to fix this? 2.What is the current limit of the analog multiplexors?I was thinking to use a discharge resistor instead of the other DAC so I can free it up to increase the resolution. 3.I was trying to use the dither module to increase the DAC resolution, but I was running into the shared bus problem (see previous post that never got answered), is there a way to do this? Thanks, -Mike
2019-03-19 07:53
我们有3个节点集群，所有3个节点都崩溃并生成转储文件。查看崩溃错误，发现所有3个节点都崩溃了相同的错误代码。所有3个节点都启用了vGPU。这是崩溃转储的详细信息;VIDEO_TDR_FAILURE（116）尝试重置显示驱动程序并从超时恢复失败。参数：Arg1：ffff8d03a76a5010，指向内部TDR恢复上下文的可选指针（TDR_RECOVERY_CONTEXT）。Arg2：fffff80d3a752678，指向负责设备驱动程序模块的指针（例如所有者标记）。Arg3：ffffffffc000009a，上次失败操作的可选错误代码（NTSTATUS）。Arg4：0000000000000004，可选的内部上下文相关数据。调试细节：------------------TRIAGER：无法打开分类文件：e：\ dump_analysis \ program \ triage \ modclass.ini，错误2FAULTING_IP：nvlddmkm + 982678fffff80d`3a752678 48ff25a145e7ff jmp qword ptr [nvlddmkm + 0x7f6c20（fffff80d`3a5c6c20）]DEFAULT_BUCKET_ID：GRAPHICS_DRIVER_TDR_FAULTBUGCHECK_STR：0x116Child-SP RetAddr呼叫站点00 ffff8a00`aaa17a58 fffff806`44b3a298 nt！KeBugCheckEx01 ffff8a00`aaa17a60 fffff806`44b1d13f dxgkrnl！TdrBugcheckOnTimeout + 0xec02 ffff8a00`aaa17aa0 fffff806`44b1a2ef dxgkrnl！ADAPTER_RENDER ::重置+ 0x15303 ffff8a00`aaa17ad0 fffff806`44b39a85 dxgkrnl！DXGADAPTER ::重置+ 0x30704 ffff8a00`aaa17b20 fffff806`44b39bc7 dxgkrnl！TdrResetFromTimeout + 0x1505 ffff8a00`aaa17b50 fffff802`e8ae2599 dxgkrnl！TdrResetFromTimeoutWorkItem + 0x2706 ffff8a00`aaa17b80 fffff802`e8b32965 nt！ExpWorkerThread + 0xe907 ffff8a00`aaa17c10 fffff802`e8bd0e26 nt！PspSystemThreadStartup + 0x4108 ffff8a00`aaa17c60 00000000`00000000 nt！KiStartSystemThread + 0x16-----------------------------02 ffff8a00`aaa17aa0 fffff806`44b1a2ef dxgkrnl！ADAPTER_RENDER ::重置+ 0x1531.所有3个故障转储指向相同的堆栈和寄存器值。FAULTING_IP：nvlddmkm + 982678fffff80d`3a752678 48ff25a145e7ff jmp qword ptr [nvlddmkm + 0x7f6c20（fffff80d`3a5c6c20）]2. Windbg堆栈指向VIDEO_TDR_FAILURE（116）。37：kd>！analyze -v>＃********* *******************************>＃* Bugcheck分析*>＃********* *******************************VIDEO_TDR_FAILURE（116）尝试重置显示驱动程序并从超时恢复失败。参数：Arg1：ffffdd84719ea010，指向内部TDR恢复上下文的可选指针（TDR_RECOVERY_CONTEXT）。Arg2：fffff80fe60e2678，指向负责设备驱动程序模块的指针（例如所有者标记）。Arg3：ffffffffc000009a，上次失败操作的可选错误代码（NTSTATUS）。Arg4：0000000000000004，可选的内部上下文相关数据。根据Microsoft文档，这是由于以下原因造成的https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x116---video-tdr-error请参阅解决方案部分*超频组件，如主板*组件兼容性和设置不正确（尤其是内存配置和时序）*有缺陷的部件（内存模块，主板等）*系统功率不足*系统冷却不足我们正在使用具有以下规范的HP服务器;HP ProLiant DL380 Gen 9和ROM版本为P89 v2.30（2016年9月13日）。 此外，当我们尝试将驱动程序升级到最新版本385.54发布日期：25.9.2017时，我们无法运行虚拟GPU（Remote FX），因为GPU未在HyperV设置中显示。一旦我们恢复到旧驱动程序376.84，我们就可以看到Hyper-V设置下的物理GPU。可以判断某人是否遇到过与Driver版本相同的问题？以上来自于谷歌翻译以下为原文We have 3 nodes cluster and all the 3 nodes were crashed and generated Dump files. Looking at the crash error found that all the 3 nodes were crashed with the same error code.vGPU was enabled for all the 3 nodes.This are the crash dumps details;VIDEO_TDR_FAILURE (116)Attempt to reset the display driver and recover from timeout failed.Arguments:Arg1: ffff8d03a76a5010, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).Arg2: fffff80d3a752678, The pointer into responsible device driver module (e.g. owner tag).Arg3: ffffffffc000009a, Optional error code (NTSTATUS) of the last failed operation.Arg4: 0000000000000004, Optional internal context dependent data.Debugging Details:------------------TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2FAULTING_IP: nvlddmkm+982678fffff80d`3a752678 48ff25a145e7ff jmp qword ptr [nvlddmkm+0x7f6c20 (fffff80d`3a5c6c20)]DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_TDR_FAULTBUGCHECK_STR: 0x116Child-SP RetAddr Call Site00 ffff8a00`aaa17a58 fffff806`44b3a298 nt!KeBugCheckEx01 ffff8a00`aaa17a60 fffff806`44b1d13f dxgkrnl!TdrBugcheckOnTimeout+0xec02 ffff8a00`aaa17aa0 fffff806`44b1a2ef dxgkrnl!ADAPTER_RENDER::Reset+0x15303 ffff8a00`aaa17ad0 fffff806`44b39a85 dxgkrnl!DXGADAPTER::Reset+0x30704 ffff8a00`aaa17b20 fffff806`44b39bc7 dxgkrnl!TdrResetFromTimeout+0x1505 ffff8a00`aaa17b50 fffff802`e8ae2599 dxgkrnl!TdrResetFromTimeoutWorkItem+0x2706 ffff8a00`aaa17b80 fffff802`e8b32965 nt!ExpWorkerThread+0xe907 ffff8a00`aaa17c10 fffff802`e8bd0e26 nt!PspSystemThreadStartup+0x4108 ffff8a00`aaa17c60 00000000`00000000 nt!KiStartSystemThread+0x16-----------------------------02 ffff8a00`aaa17aa0 fffff806`44b1a2ef dxgkrnl!ADAPTER_RENDER::Reset+0x1531. All 3 crash dump points to same stack and register value. FAULTING_IP: nvlddmkm+982678fffff80d`3a752678 48ff25a145e7ff jmp qword ptr [nvlddmkm+0x7f6c20 (fffff80d`3a5c6c20)]2. Windbg stack points to VIDEO_TDR_FAILURE (116).37: kd> !analyze -v>#*******************************************************************************>#*Bugcheck Analysis*>#*******************************************************************************VIDEO_TDR_FAILURE (116)Attempt to reset the display driver and recover from timeout failed.Arguments:Arg1: ffffdd84719ea010, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).Arg2: fffff80fe60e2678, The pointer into responsible device driver module (e.g. owner tag).Arg3: ffffffffc000009a, Optional error code (NTSTATUS) of the last failed operation.Arg4: 0000000000000004, Optional internal context dependent data.As per Microsoft documentation this is cause by following reasons https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x116---video-tdr-errorRefer to Resolution Section*Over-clocked components, such as the motherboard*Incorrect component compatibility and settings (especially memory configuration and timings)*Defective parts (memory modules, motherboards, etc.)*Insufficient system power*Insufficient system coolingWe are using the HP Servers with following specification;HP ProLiant DL380 Gen 9, and the ROM version is P89 v2.30 (09/13/2016). And moreover when we tried to upgrade the drivers to the latest version 385.54 Release Date: 25.9.2017 they we were unable to run virtual GPU (Remote FX) as GPU does not show in the HyperV setting. Once we reverted to old driver 376.84, we could see physical GPUs under Hyper-V settings.Can any tell if someone has experience the same issue with the Driver version?
2018-09-12 15:52
