I am starting to use stm8s003. I use the stm8s003 board like this:
"https://www.cnx-software.com/wp-content/uploads/2015/01/One_dollar_development_board.jpg".
When I use IAR and download the program to my stm8 this error occurs :
"The Flash Memory Read-out protection option must be disabled for
debug. Disabling this option will first erase the whole Flash Memory."
and I can't debug. How do I disable read-out protection?
You can disable Read-out protection by reset option bytes(using ST-Link Utility) but I suppose your code will enable protection again, so you have to ensure that during debug session your code does not enable ReadOut protection. You can use Release/Debug configuration to manage this issue.
Related
I don't want to find some disabling of gatekeeper where I just turn it off completely.
However, I use SQLiteStudio probably more often than majority of the applications on my computer, but every single time I open it (which I try to avoid and just keep it open constantly) it requires that I go into Security & Privacy and hit "Open Anyways" to force it to open since it's apparently from an unidentified developer...
Anyways, I'm hoping there's some fix or something I can do to permanently disable the warning for this particular application only?
Most other applications when I download them and open them and they have that issue it only occurs the single first time I open it - and then when I hit "Open Anyways" it disables the warning from then on. But this application is the exception and I'm really hoping for a solution. Any help???
This is the first time that I use the release mode in VS, I always used the debug mode and I'm really impressed by how the code can be optimized in release configuration!
But anyway I was surprised that I could still use the "Local Windows Debugger" even in the release configuration, especially because it seems that debug in release mode is not obvious (while in my case I didn't change any option). So my questions are:
Is that normal that the "Debug Information Format" in release mode is set to /ZI? I noticed that if I disable this information no breakpoints work anymore, so maybe I changed it unintentionally.
The code execution in Local Windows Debugger (F5) in release mode is slower is slower "Start without debugging" (CTRL+F5)?
1) Without any debug information, breakpoints just can't work as there is no way to associate a specific code line with an address in the binary.
(Actually, placing a break point on a specific instruction in the binary will still work, only mapping it back to the source code won't.)
If you lower the debug information format from /ZI to /Zi, further optimizations will be enabled, but in return certain debug features like live editing variable contents already become unavailable. See also https://msdn.microsoft.com/en-us/library/958x11bc.aspx for more details.
2) No, just spawning the debugger usually has no impact on performance.
This is unless actually using break- and trace points, in which at most the first 4 breakpoints are handled in hardware, and all following ones bring an overhead.
Tracing and profiling always causes overhead.
I just started using the ms Detours library, and I would like to know how to hook an exe file using it. I got the function offset from IDA Pro, however i don't know what address should hook to. It gives a access violation if I hook to the offset using the withdll.exe tool. Could someone show me an example of hooking an exe if it is possible?
The StackHash crash happens because you are probably trying to execute code from the page that does not have EXECUTE access. You can disable DEP just to make sure this is the cause for the crash. Subsequently, if this is indeed the case, you should use VirtualProtect or VirtualProtectEx to modify the page protection using one of the protection constants that include EXECUTE access (you can see the list of the constants here). As per the address/offset calculation, I don't see any problem with that in your description.
Below are the instructions on how to disable DEP:
Click on the Start menu and then go to the Control Panel.
Click on System Maintenance and then System.
Choose Advanced System Settings.
Under System Properties, select Settings from the Performance section at the top.
Click on the Data Execution Prevention tab.
Select “Turn on DEP for all programs and services except those I select”.
Find the executable file for the application that triggered the error.
Select the application causing the error and click Open to add it to your DEP Exceptions list.
Click OK to save your new settings.
Hope this helps.
I have a corruption memory heap with my application. I would like to use Application Verifier in order to find the bug.
I have some difficulties to find a tutorial on how use Application Verifier.
One of the first question I'm wondering is should I use my application in DEBUG or RELEASE mode ?
Thanks
Typically, in debug mode with a debugger attached will be your first stop. This provides full run-time checks, more validation, and more accurate information on what is going wrong. Application Verifier can also signal the debugger to break and will output error information, so having a debugger attached is very useful.
After that, as Simon Richter noted, you'll want to run most of it again in release. Release builds typically don't have the same checks and don't watch for errors, so things are very likely to surface that weren't an issue in the debug build. There is some use for a sort of manual-debug or hybrid build, where you perform some of the checks and logging to make sure things don't go too far afield.
To use Application Verifier, you really just need to start it, add an application and enable to desired tests. When you run, it will create a log and send messages/breaks to a debugger if one is around.
With the necessary experience in debugging, "Both" would be the right answer, as the differences between Debug and Release builds also give good hints about the source of the problem.
If you do not want to dive that deep into the inner workings of the compiler, then use the Debug version if the error appears there reliably.
usually debug versions run the application verifier to find the bugs in the app.
On xp, every time a process would crash the OS would pop up a dialog asking if I would like to debug the process. I cant find a way to enable this functionality on the later version of windows. So to reiterate, I want to attach a debugger to a native process that's auto broken on a crash.
Does anyone know how to get this done?
Enable Just-In-Time debugging.
Edit: since that doesn't work for you, some additional suggestions -
Make sure the AeDebug registry key values are correct.
Setup WER to create full crash dumps, and debug the dumps.
Not sure about this, but is it possible your user doesn't have debug permissions? Have never checked that, but I assume this would prevent that user from being offered a chance to debug the process (and even if you do, UAC might circumvent them - but I don't know this for a fact).
I think what you're looking for is the Dr. Watson tool. This KB article explains how to disable or enable it.