I have encountered a weried problem about _CrtIsValidHeapPointer in a debug version of a dll, which compiled using msvc2017 compiler. When the debug version (with debug version of vc runtime) is loaded and running, the performance is terrible. I confirmed that most of the cpu is consumed by the calling to _CrtIsValidHeapPointer, which is called from operator delete or free(C function). Because it it pretty common to allocate and free object on the heap, the _CrtIsValidHeapPointer is called often and it leads to very laggy interaction, and somethings may cause the program to be unresponsive.
I have tried many different methods, here is what I found:
Linking with static lib version or dll version of the VC CRT makes no difference.
Using WinSDK 8.1 or 10.0 makes no difference
When running the dll under Win10 1803, it works fine. Under Win10 1809, laggy and unresponsive.
Now I have no idea why the Win10 version lead to a different behavior and how.
Any help will be appreciated.
Related
I am working on a IddCx indirect Display Driver. I have run into a bug that I cant find any reason to blame my own code on. Every two seconds or so IddCxSwapChainReleaseAndAcquireBuffer takes over 100ms, up to 8000ms to complete. It normally takes below 16ms to complete (depends on your frame rate).
I even added timestamps to the IddCx Sample code from Microsoft. It still has this issue, so it cant be a fault with my own code. I have exhausted most of my debugging options.
Changing IddCx versions I am compiling with (1.4 to 1.8) by targeting the libs, the headers, and defining the macros (IDDCX_VERSION_MAJOR, IDDCX_VERSION_MINOR, IDDCX_MINIMUM_VERSION_REQUIRED). 1.9 btw doesnt seem to run well, IddCxDeviceInitConfig() fails with Invalid Parameter if I choose version 1.9.
Changing which UMDF version I am compiling with (2.25 to 2.33).
Changing the Windows SDK version I am using (10.0.19041.0, 10.0.20348.0, 10.0.22000.0, 10.0.22572.0).
Swapping my OS to the Insider Program preview version of win11 (currently 22000.588 co_release).
Things I think may be solutions that I need help on.
When I am running the Driver, within dxdiag, the display says its using WDDM version 1.3, while my other displays use WDDM version 3.0. WDDM 1.3 is old, so maybe this could be causing issues? How do I tell visual studio to compile my driver to compile with WDDM version 3.0? Does my driver need to WHQL Logo'd first?
IddCxGetVersion() returns with version 1801 or 1803 no matter what I change (SDK, IDDCx version, etc), which is from 2018! So what am I doing wrong here to get the OS to choose to use a newer version of IddCx? This may be related to the WDDM version being 1.3 instead of 3.0.
Swapping back to Windows 10. I originally swapped to Windows 11 because the WDK dev environment is completely unstable, with the samples sometimes not creating functional drivers, that fail to call into 'EVT_IDD_CX_ADAPTER_INIT_FINISHED', I have confirmed its being compiled incorrectly (sometimes) on windows 10, and the old dlls from earlier that day will still work, but the new dlls will not. So thats why I am staying with Windows 11, I also need to swap to Windows 11 anyways since we should be moving forwards, not backwards.
forgot to close this.
Realized the issue was that the monitor desktop simply wasnt updating. So the OS was just rendering the desktop less often, resulting in less frames being pushed to the swapchain for me to grab
I'm running Windows 7 Pro, SP1 on a Dell Precision M2800 (I know it's out of date).
My VMWare Workstation version is 11.1.4 build 3848939. Right now I'm using it primarily for a VM with Windows 7 and a bunch of (latest) Rockwell/Keyence software.
I'm using CodeBlocks version 16.01 to compile C++. Packages I'm using in my code include various SDL libraries and the standard stuff.
The issue I'm having is repeatable for me:
I start both VMWare and CodeBlocks running on my host machine. I compile and test code in CodeBlocks while I wait for Rockwell to finish compiling/uploading/etc.. After a couple of times compiling and running programs with CodeBlocks, my host OS will lock up for a long time (more than an hour). I haven't waited long enough to see if it ever unlocks on its own.
The work-around I'm using right now is to just not use those programs at the same time. I'm not necessarily looking for a solution, (because I anticipate that everyone will just tell me to update Windows), although solutions are fine. I'm looking for information about the root cause. Anybody have ideas about why this might be happening?
Thanks in advance.
I've been using clang successfully on Windows XP and Windows Vista using the 'experimental' builds for MinGW, but now that I try on my new Windows 7 64-bit laptop it simply crashes. Even if I just run "clang++" or "clang" it crashes, and I can't figure out how to get windows to give me more detailed crash info (I will edit that in if I can). I've redownloaded clang and reinstalled MinGW, and I've tried running clang.exe in compatibility mode, but it still doesn't work. This is the first time I am using it on 64-bit, I hope that's not the issue (if it is, I still have another computer I can use).
I've looked around and can't find anyone else having this same problem with clang crashing before even giving any output or processing any input, I really feel lost.
This has now happened multiple times on various system and I have found the solution. Reinstall MinGW using the prepackaged files, the 'latest' ones have a tendency to be unstable in relation to clang. Make sure you haven't also installed a newer version of gcc on top of the MinGW installation, as that will cause issues too.
I have two machines, one running Vista Ultimate 32, the other one running XP SP3. both machines have the same VS2008 version installed.
I built boost 1.50.0 on the first machine (vista), and subsequently libtorrent library, that relies on boost.
I saw in some libtorrent build instructions that the win version is specified within preprocessor, so I did what seemed to make sense at the moment:
#define _WIN32_WINNT=0x0600 // being that the current OS is Vista
The build went successfully, and I was able to run the application on that machine. However, when I tried to run it on the other one (XP), it failed with the message, something like:
Procedure entry point SetFileInformationByHandle could not be located in the dynamic link library KERNEL32.dll
Now, logically, I'm guessing that this has something to do with incompatible versions, and probably different windows headers are included when this variable exists with different values.
The requirement: I'd like to build this on Vista or 7, and still be able to run it on XPs.
The question: Do I need this directive at all, and if I do, what should be the value? What else should I specify, if I'm missing something?
Try to build your program on XP or set _WIN32_WINNT to 0x0501 (as in your comment). The kernel32.dll library is backward binary compatible according to this report, so you can build your program with old version of this library (5.0) and run it with a new one (6.0) without the need to recompile. Vice versa is not possible due to a bunch of added symbols (SetFileInformationByHandle is one of them).
Ok, this seems like a dumb question because MonoDevelop is getting more mature, so I'm sure I'm just missing it, but I looked around and all the questions about this subject seem to be about remote debugging or debugging on a Mac.
I'm using Ubuntu 10.04 Lucid Lynx, and I just installed MonoDevelop 2.2.1 from the software center.
I created a GTk# 2.0 project, added some widgets and code and everything seems to run fine. Then I added a breakpoint, and it shows up in my breakpoints window, and it says it's active, but the breakpoint never actually hits(stops execution and pulls me into the debugger).
I'm in Debug x86 mode, so I can't figure out what's going on.
Anyone have this happening/know what to do about it?
I'm having the same problem (also on Ubuntu 10.04) and found kind of a hack that is working for me. Instead of setting a breakpoint in the IDE (by clicking on the side or hitting F9), make a call to the System.Diagnostics.Debugger.Break() method in your code where you want the execution to break. After doing that, I am able to step through the code, use the immediate window, etc. Obviously, it's not a very good solution, but at least it's something.
To check whether you have a debugger installed, simply check whether the "Run" menu contains a "Debug" command.
You should be aware that Ubuntu ships a rather old version of Mono (2.4) which has no built-in "sdb" debugger, and its version of MonoDevelop 2.2 is patched to remove the sdb interface. To get semi-functional debugging, install the old "mdb" debugger - the mono-debugger and monodevelop-debugger-mdb packages, IIRC.
To get the best debugging experience (sdb), you need Mono 2.6+ and an unmodified MonoDevelop 2.2+. If you decide to build Mono from source, please read this and this first. Alternatively, you could use openSUSE, which has up-to-date Mono and MonoDevelop packages available.
What versions of Mono runtime and debugger are installed? I tried it with monodevelop 2.2 + mono 2.6 + debugger 0.0.0 under Windows and it works just like expected. Here is a quotation from mono's website, which may be helpful:
Mono comes with two Mono-specific debuggers: a hard debugger and a soft debugger, additionally, you can use the Unix GDB debugger with Mono to debug low level problems
...
Soft Debugger:
...
Moonlight, ASP.NET, Gtk#, iPhone and remote debugging supported
Maybe the problem is in a code? What do you mean by:
... (stops execution and pulls me into the debugger).