i am creating a Windows CE 6.0 in Visual Studio 2005 with Platform builder. I integrated a stream device driver (via USB HID). I also have a small application that opens a connection to the device and reads data from it. When i build a Debug-Version of this Windows CE 6.0 and debug it on the device i can start the application and the communication to the device works fine. Now i build a Release-Version (no changes of Sources!) of the Windows CE 6.0, run it on the device and start the application on the device. When i try to read data from the device by ReadFile(), (i guess this calls XXX_Read() from the stream driver) my windows crashes and reboots. Its too bad, because i cant debug the CE where the windows exactly crashes... (because it does not crash in debug version ;).
What are the differences between Debug and Release Version of WinCE 6? Does anyone have a hint at which part of the Stream Device driver i need to have a closer look to solve this problem? I know that in Debug/Release the Project settings are not adopted. But i cant think of any setting that may influence the stream device driver.
Regards
The big difference between Release and Debug is that in a Debug build of code all variables get initialized to zero. In Release they do not get initialized at all and therefore often can end up with whatever non-zero garbage was in the storage location of the variable when it was allocated.
This is often a problem if you're creating pointers in your code and then checking them against NULL. A Debug build will tell you the pointer is NULL because it got initialized to zero. In Release it ends up non-zero, then you try dereferencing the garbage in the pointer and it causes an access violation crash.
The moral of the story: always, always initialize your variables in code. ZeroMemory/memset is your friend.
One thing you could do is to setup Dr. Watson so that you can generate a KDMP file when the crash occurs, then you can do a post-mortem debug analysis with the KDMP file to see where the crash is happening. See the docs to get more info on setting up Dr Watson on WinCE 6.0.
Once you have generated the crash dump file (*.KDMP), you can use Visual Studio 2005 to open the KDMP file (File | Open Project/Solution). Once it's loaded, use the Target | Attach device menu option to start the post-mortem debug session (Note that you are virtually "attaching" to the device via the KDMP file, you do not need to physically access the target device while post-mortem debugging)
You can also leave KITL and Kernel debugger enabled in your release image.
When you debug release code you will experience some strange behaviours (code not executed in order or multiple instructions executed in a single step, some variables can't be watched because they are stored into registers etc.), but you should be able to understand where your system crashes. If you have a watchdog this may be enabled only in release builds and that could explain the reboot.
Related
I am running Visual Studio Community 2015 and visualGDB and building an embedded application for STM32. Every tutorial only shows how to debug the project, but is it possible to flash the code to the device as it is possible form other IDEs?
Yes - In your project settings under "Debug Method", you will set your Programming interface. (In my case I am using an STM32F072 Discovery board, with its integrated ST-Link V2 interface.) This same interface is used for both programming and debugging.
When you start a debug session, it will compile your code, flash your device, and then start executing in debug mode. You can also just "run" the program, which will build and flash your code and execute it without debugging.
Either way, the program will remain on your device, so for an individual hobby project you can "deploy" after a successful debug/run session if you want.
If you want to flash multiple devices without building every time (i.e., for production), I'm not sure if there is an option for that. It might be better to just use the ST-Link utility outside of Visual Studio/VisualGDB.
Did you look for stLink tool provided by ST. Take a look on 'visualGDB StLink and openOCD'
i coded a big project in c++ that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs after 5 seconds. It just doesn't reply anymore and is tagged as inactive in taskmanager. I tried to analyse the error with the windows debugger tools and application verfier, but i found nothing. Even when I set the "_NO_DEBUG_HEAP=1", the error doesn't occur, it just happens when I start it with ctrl + f5 or outside from visual studio. I'm not even sure if the _NO_DEBUG_HEAP works... Anyone have an idea what could be wrong ?
Any number of things may cause this.
Based on my passed experience, I suggest tackling this by removing code until the behaviour disappears... then determining why removing the code in question corrected the behaviour. (the removed code may not have been the cause, only a catalyst for the symptom)
If I was tasked with taking a quick glance to spot the error, I would think to look for buffer overrun related issues. This type of error has more safeguards in debug than executing a final build. That's just a stab in the dark based on buffer overruns being a common issue that kinda fits the symptom.
-dm
Common things to check:
Are you sure your application is setting any memory used to zero,
if it is assuming the memory has to be zeroed out?
Visual Studio might be initializing the memory given to the
application.
Is all the memory allocated being deallocated?
There are no un-initialized pointers being used?
There are no un-initialized variables being used?
64 bit exe crashing outside visual studio but working inside visual studio
Does the problem only happen on one computer?
You can use check_heap to check the validity of the heap
in the program:
Program crashes only in Release mode outside debugger
You can use the Windows debugging tools to show heap
corruption - there is a tool called "gflags" that comes with the
Microsoft "Standalone Debugging Tools for Windows"
https://msdn.microsoft.com/en-us/windows/hardware/hh852365
This URL shows how to run gflags against your .EXE:
Visual Studio - how to find source of heap corruption errors
I'd like to know what sets the "Debug with Nsight" option apart from simply executing the binary through Visual Studio or the OS's command line.
The reason I ask is because my program works fine if I run it by "Debugging with Nsight", but I get a few unspecified cudaErrors with some cudaMemcpys following a driver crash when launching it with Visual Studio's launch button (or simply launching the executable), which leads me to believe that Nsight must have some kind of specific launch parameters necessary for the program to run correctly.
The driver crash followed by API errors occurs when your app hits a windows TDR event due to kernel execution taking too long. You can work around this by modifying the system registry, or putting a Quadro or Tesla GPU in TCC mode, or reducing the run-time of your kernel(s).
When you debug with nsight, your kernel execution may get halted for various reasons (single step, breakpoints, and other reasons), and then restarted, depending on what you are doing exactly in your debug session. The halting of the kernel execution allows the windows watchdog to be satisfied without a TDR event.
CUDA nSight debugger allows you to debug the CUDA kernels line by line, you can't do this with the standard Visual Studio debugger.
Presumably nSight performs some code injection to enable it to detect the runtime of kernels, its also possible on your settings that when debugging with nSight your kernels may not be executing on the GPU. These could be the cause of errors coming and going between debuggers. I know when I used them I had similar inconsistencies.
If you run your program through the nSight profiler it should be able to clearly log the memCpy errors for you.
I have a completely random error popping up on a particular piece of software out in the field. The application is a game written in VB6 and is running on Windows 7 64-bit. Every once in a while, the app crashes, with a generic "program.exe has stopped responding" message box. This game can run fine for days on end until this message appears, or within a matter of hours. No exception is being thrown.
We run this app in Windows 2000 compatibility mode (this was its original OS), with visual themes disabled, and as an administrator. The app itself is purposely simple in terms of using external components and API calls.
References:
Visual Basic for Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OLE Automation
Microsoft DAO 3.51 Object Library
Microsoft Data Formatting Object Library
Components:
Microsoft Comm Control 6.0
Microsoft Windows Common Controls 6.0 (SP6)
Resizer XT
As you can see, these are pretty straightforward, Microsoft-standard tools, for the most part. The database components exist to interact with an Access database used for bookkeeping, and the Resizer XT was inserted to move this game more easily from its original 800x600 resolution to 1920x1080.
There is no networking enabled on the kiosks; no network drivers, and hence no connections to remote databases. Everything is encapsulated in a single box.
In the Windows Application event log, when this happens, there is an Event ID 1000 faulting a seemingly random module -- so far, either ntdll.dll or lpk.dll. In terms of API calls, I don't see any from ntdll.dll. We are using kernel32, user32, and winmm, for various file system and sound functions. I can't reproduce as it is completely random, so I don't even know where to start troubleshooting. Any ideas?
EDIT: A little more info. I've tried several different versions of Dependency Walker, at the suggestion of some other developers, and the latest version shows that I am missing IESHIMS.dll and GRPSVC.dll (these two seems to be well-known bugs in Depends.exe), and that I have missing symbols in COMCTRL32.dll and IEFRAME.dll. Any clues there?
The message from the application event log isn't that useful - what you need is a post mortem process dump from your process - so you can see where in your code things started going wrong.
Every time I've seen one of these problems it generally comes down to a bad API parameter rather than something more exotic, this may be caused by bad data coming in, but usually it's a good ol fashioned bug that causes the problem.
As you've probably figured already this isn't going to be easy to debug; ideally you'd have a repeatable failure case to debug, instead of relying on capturing dump files from a remote machine, but until you can make it repeatable remote dumps are the only way forwards.
Dr Watson used to do this, but is no longer shipped, so the alternatives are:
How to use the Userdump.exe tool to create a dump file
Sysinternals ProcDump
Collecting User-Mode dumps
What you need to get is a minidump, these contain the important parts of the process space, excluding standard modules (e.g. Kernel32.dll) - and replacing the dump with a version number.
There are instructions for Automatically Capturing a Dump When a Process Crashes - which uses cdb.exe shipped with the debugging tools, however the crucial item is the registry key \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
You can change your code to add better error handling - especially useful if you can narrow down the cause to a few procedures and use the techniques described in Using symbolic debug information to locate a program crash. to directly process the map files.
Once you've got a minidump and the symbol files WinDbg is the tool of choice for digging into these dumps - however it can be a bit of a voyage to discover what the cause is.
The only other thing I'd consider, and this depends on your application structure, is to attempt to capture all input events for replay.
Another option is to find a copy of VMWare 7.1 which has replay debugging and use that as the first step in capturing a reproducible set of steps.
Right click your executable object and let it be WINXP compatible pending
when you discover source of the problem to finally solve it
My winform application crashes as soon as its been launched. This problem is only happening in one of the client computer. Works fine for all other clients. I was thinking of using ADPlus to get a crash dump but problem is in order to configure ADPlus in crash mode, debugger need to be attached to running application first. That means application must be running when I configure ADPlus, however, as I said my application crashes as soon as I start it. It does not give me a chance to run ADPlus. Any idea if ADPlus can be used in this scenario? Are there any other tools that I can use generate a process dump in this case?
Since you can't start the program and then attach a debugger in time, you can try one of the following ideas:
Start the program under the debugger on the machine where it's crashing. As already mentioned, ProcDump is enough for that purpose, or you can use Visual Studio or WinDBG.
If you can't easily start the program under the debugger (for example, if it is actually a Windows service), use gflags to make Windows start the program under the debugger. This will create a subkey for your program filename under the Image File Execution Options registry key.
Set your debugger as the postmortem debugger, so it always launches when any program crashes.
If and when the crash happens, the debugger will automatically break in and either create a dump automatically or let you create one manually.
If you can't run a debugger, not even ProcDump, you can use Windows' built-in crash dump facility to create a dump automatically:
On Windows XP and Windows Server 2003, set Dr. Watson as the postmortem debugger by running this command:
drwtsn32 -i
Here is info on what this command does and how to use Dr. Watson: Capturing Application Crash Dumps
On Windows Vista SP1, Windows Server 2008, and later, set Windows Error Reporting to save dumps locally by creating this registry key:
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
You don't need to create or set any values or subkeys under this key. If you want to change settings, here is more info: Collecting User-Mode Dumps
Note that "applications that do their own custom crash reporting, including .NET applications, are not supported by" WER. This is a problem for you because your app uses WinForms - although there is some indication that the feature does work with .NET 4 apps on Windows 7.
You can use ProcDump from Sysinternals to capture a dump.