Standalone IntelliTrace generate small corrupted traces - intellitrace

I'm trying to use IntelliTrace Standalone on Server, and I'm using the following commands to Start / Stop tracing, I can't figure out why this is not working for me, each time I got a small corrupted trace file.
C:\IntelliTraceCollection\IntelliTraceSc.exe /n:myApp /f:C:\IntelliTrace\myApp.itrace /cp:C:\IntelliTraceCollection\collection_plan.ASP.NET.trace.xml start "c:\myApp.exe"
C:\IntelliTraceCollection\IntelliTraceSc.exe stop /n:myApp /cp:C:\IntelliTraceCollection\collection_plan.ASP.NET.trace.xml

Related

Ocean API: A debugger has been found running in your system. Please, unload it from memory and restart your program

I wrote a simple code in Ocean API. When i want to start it without debugging it works and i can see the plugin in Petrel. However when i try to debug it a message appears:
cEngineer.dll A debugger has been found running in your system.Please, unload it from memory and restart your program.
Error- Debugging Mode
How can i solve this issue?
Many Thanks,
Petrel cannot be started in Debug mode. You can attach the debugger to it after it is launched. One trick to get the debugger attached early in your plug-in code is to place:
Debugger.Launch();
in your IModule.Initialize method.
The 64-bit version of Petrel is hardened against reverse engineering during initialization, but the previous answer is correct: attaching later (e.g. with Debugger.Launch(), or manually after the UI has appeared) works fine.
Alternatively, you can use the developer-only 32-bit build of Petrel (check the Ocean developer site). Pure .NET-based plugins will work fine, and it can be launched directly in the VS debugger.

Using VMMap in a batch script

I am doing some analysis work on some software we are running where I work. The software seems to have memory issues some where along the line which are proving difficult to track down. We have decided to use Sysinternals VMMap to track the memory being used by the software.
We have VMMap exporting the usage every 20 seconds using Windows scheduler to launch a batch script which pulls back the target process PID and launches VMMap with it. The process runs for a while, output appearing the out directory but after a while it stops. Windows scheduler reports the job ran fine and will start another instance when the trigger is meant, once again with no output.
After a bit of investigation it looks like VMMap is failing to open the process and is trying to report an error through its GUI. Since we are running in batch, we cannot see this error to dismiss it. This is causing numerous process' to be spawned but not actually doing anything.
Has anyone come across this issue when using VMMap, or know of anything that may help? I am thinking there may be some flag I can pass which suppresses messages or maybe some way I can handle it in the batch but Google hasn't helped nor has the Sysinternals forum. Any help would be really appreciated.
VMMap is a GUI tool, so trying to capture its output in an automated way will be difficult. Instead, try using another SysInternals tool, Handle, that captures a lot of the same information, but exports/reports on it in command line, where it can be captured much easier. Alternatively, don't run the output in an auto-repeating way when using VMMap, but instead have your script somehow detect the error or missing expected results/data and stop so the GUI output can be examined.
All Sysinternals tools do pop up a consent dialog for the first time they are started on a new machine to accept their license. I think you did deploy the tool to a production machine and it was trying to show the consent dialog but nobody did press ok.
They do basically create a registry key on the machine which you can fake if you need a fully automated deployement or you can start in once on the target machine for the user in question.

Application works properly in console but terminate in window service

I made an console application in Visual c++ in VS 2010. I added the console handler so that when I press Ctrl+C the application may terminate successfully and it worked for me without error. Later I put the application into a window service and called the same console handler in service console handler in the following the cases SERVICE_CONTROL_STOP and SERVICE_CONTROL_SHUTDOWN. When I stop the service I get the error
HEAP CORRUPTION DETECTED:after Normal block(#119) at 0x003C5420.CRT detected that the application wrote to memory after end of heap buffer.`
What should I do to fix this?
You need to analyze dump files that are created after this failure.
So the first step is setup collecting dump files.
Then build your program in release mode with pdb-files and run it as windows
service.
Finally when you have dump files for this failure you can
use your debugger to analyze them. I often use for this purpose
WinDbg.

Detect/Redirect core dumps (when a software crashes) on Windows

For my work, I need to create a service that will detect an abnormal program termination and, instead of displaying a message to the user (default behavior), send the generated core dump to a remote server.
I'm pretty sure this can be done, but I have absolutely no clue on where to start. Is there any API/registry settings for this ?
Thank you.
One method is to install an Unhandled Exception Filter and then write a minidump from it which you can then upload to some place of your choosing. I wouldn't totally disregard Windows Error Reporting -- that's an addition to any crash reporting of your own. If your application is for public release then registering for Windows Error Reporting is well worthwhile as you get information about which crashes users are encountering in the wild and when crashes have been fixed you can add a response code to point them to a new version or other relevant information.
Another tool that may be useful depending on how your application is deployed in your organisation is to run Adplus on a user's machine which will collect together crash dumps. This is more useful for one-off crashes that seem to affect an individual user but aren't reproducible in a development environment.
Some other useful links:
http://www.debuginfo.com/articles/effminidumps.html - some useful sample code
http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
It seems my question was either obvious or stupid (both ?) but anyway, i found some interesting pages after some researches.
Here are the links I found useful:
Track application crashes and disable Windows Error Reporting at the same time!
Disable error reporting

IIS crashes when serving an ASP.NET application under heavy load. How to troubleshoot it?

I am working on an ASP.NET web application, it seems to be working properly when I try to debug it in Visual Studio. However when I emulate heavy load, IIS crashes without any trace -- log entry in the system journal is very generic, "The World Wide Web Publishing service terminated unexpectedly. It has done this 4 time(s)."
How is it possible to get more information from IIS to troubleshoot this problem?
Download Debugging tools for Windows:
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
Debugging Tools for Windows has has a script (ADPLUS) that allows you to create dumps when a process CRASHES:
http://support.microsoft.com/kb/286350
The command should be something like (if you are using IIS6):
cscript adplus.vbs -crash -pn w3wp.exe
This command will attach the debugger to the worker process. When the crash occurs it will generate a dump (a *.DMP file).
You can open it in WinDBG (also included in the Debugging Tools for Windows). File > Open Crash dump...
By default, WinDBG will show you (next to the command line) the thread were the process crashed.
The first thing you need to do in WinDBG is to load the .NET Framework extensions:
.loadby sos mscorwks
then, you will display the managed callstack:
!clrstack
if the thread was not running managed code, then you'll need to check the native stack:
kpn 200
This should give you some ideas. To continue troubleshooting I recommend you read the following article:
http://msdn.microsoft.com/en-us/library/ms954594.aspx
Crash dump of asp.net process should give you tons of info..If you want to quickly get some info on why the process got recycled, try this tip from Scott Gu..
Health monitoring feature of asp.net 2.0 is also worth looking at..
The key is "without any trace". You need to put your own trace logging in to create some chatter. Then you'll be able to spot where the chatter stops.

Resources