Does the same technique which FastMM4 for Delphi provides to report memory leaks to a detailed file work if the application runs as service? Of course the best practice would be to write unit tests and a simple standalone application first, and find the leaks there, outside the service environment.
As Lars Truijens notes, writing to a log file requires file system privileges. The default Local System account (i.e. when you do not set an account explicitly or logon in your code) has full access to the local file system but has no default network access.
FWIW - I typically develop my services as regular Windows apps until the main part of the logic is up and running and stable. Using a library like SvCom allows you to run your services as a regular desktop application or as a service without any code changes.
Yes, provided the account used to running the service has enough rights to write the log file.
I am having the same challenge at the moment. I tried this, but it does not work, at least so far for me. There are sufficient rights for the account, since the service can write his own proprietary logfile. I have switched on FullDebugMode and added the dll, I have switched on LogMemoryLeakDetailToFile, both via the IDE options. In the code I see that the right areas are seen by the compiler, when I provoke an error for example, the compiler reports it. Also I cannot debug the FastMM code. If I put a breakpoint it is ignored. I have searched all my local hard disks where that report might be gone to, it is not to be found. I start and stop the service from 'Administration-Services', all goes well, it starts up, but no report. If I do the same with a normal executable, all goes well. I am using FastMM478, and Delphi2007.
Marc
Ok I found out another reason why sometimes you cannot see any output, logfile or messagebox......
If you do not make any error, it does not create any output.
So to test if FASTMM478 works deliberately make an error in your program like:
//Create and to NOT destroy
testToMakeError := TStringList.Create;
for I := 0 to 100 do
testToMakeError.Add('foobar');
I just presumed I would have made some error somewhere and spend a day trying to find out why the program did not gave me any feedback.
Marc
Do the instructions as described in the readme file for FastMM
Enable {.$define NoMessageBoxes} in FastMM4Options.inc File
Disable {$define RequireDebuggerPresenceForLeakReporting} in FastMM4Options.inc File
Install/Start Service and after stopping it you will get MyApp_MemoryManager_EventLog File in output folder.
Related
I found interesting problem with Win7/X64 machine.
For this time I haven't got problem with Delphi 6 and UAC.
The exes are working in their's place, so I can use Delphi debugger with them.
But today I got error on run the project: "Unable to create process. For this operation you need higher user level".
How can I prevent this side-effect?
What causes this?
I don't understand why the older projects are running fine, but this new isn't...
Thanks for every idea, link, information!
Additional info:
Normally I using the Delphi 6 IDE with normal starting (without SysAdmin rigths).
So it is never asking me with "really?" kind UAC questions.
And every of the older projects are usable with Delphi 6 - I can build, run, debug everything.
This problem happened with only this project, so I try to find the differences if possible to solve the problem.
I using normal directory ("c:\dev\anyproject"), others are using "c:\dev\otherproject1..2..n").
Does your application request elevation when started from Windows Explorer?
Does it have a manifest?
The name of the exe, like setup.exe, could also trigger elevation. See an outline of the Installer detection technology.
Non-elevated process can't debug elevated process.
If your application requires elevation at the start, then you would need to run the IDE elevated to be able to debug it.
Starting your IDE as an administrator should solve the problem (option in the context menu).
If not, you could always disable UAC while developing.
There is a number of limitations that needs administrator's rights.
For example: you cannot write data directly into program files directory.
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.
Using Delphi 7, I wonder if there is a free component which will collect diagnostic information as my application runs at a remote site and will help me to debug error reports.
Maybe it records each menu item selected, control clicked, text input, etc? Maybe it just dumps the stack on a crash. Maybe it does something else ...
I don't mind adding code (e.g at the start and end of each procedure), as that might generate more useful info than a fully automatic system.
I am not sure if the solution ought to "phone home" or if it is enough to produce a text file which can be emailed to me.
Any suggestions?
with the crash debuging have a look at MadExcept
http://www.madshi.net/madExceptDescription.htm
madExcept was built to help you locating crashes in your software. Whenever there's a crash/exception in your program, madExcept will automatically catch it, analyze it, collect lots of useful information, and give the end user the possibility to send you a full bug report.
free for non-commercial usage, inexpensive for commercial usage
or JclDebug from the JEDI Code Library
http://www.delphi-jedi.org/
A Blog Posting about it can be found here
http://www.gnegg.ch/2002/12/jcldebug/
EDIT: This seems to be a very good example on how to use JCLDebug
http://robstechcorner.blogspot.com/2009/04/finding-hard-to-reproduce-errors.html
I use EurekaLog http://www.eurekalog.com
It does the call stack, memory contents, other apps running, a good description of the machine, OS, patches, etc.., It can (with user permission, and if configured to to so) take a screenshot, ask the user for input (what were you doing when it crashed?), etc.. It can send the dump via e-mail, post to http, post directly to bug trackers like Mantis and FogBugz, or just leave it on the system. It's great, and well supported.
Also, here's a link to a similar question
Compare Delphi Exception Handlers
Have you looked at the open-source JclDebug from Project Jedi? Here's a nice succinct write-up on JclDebug.
Imagine you could get a detailed
error-report containing a full
callstack of where the error occured
combined with information about file
and line-number. This report could be
generated directly on the users
computer and be sent to you via email
or directly via the internet, using a
custom procedure - even directly
creating entries in the
bugtracking-tool you are using.
This and more is made possible by the
Project JEDI - more accuratly, the
JCL-Subproject with its
JclDebug-Framework. When you have
completed the installation of the
package, a new Menu Option called
"Inser JCL Debug Data" will be added
to the Project-Menu of your
Delphi-IDE.
There is a great delphi porting of the most known opensource logging framework written in java, Log4J: it is called Log4Delphi.
http://log4delphi.sourceforge.net
I downloaded it, extended and used with my projects with success.
Best features: opensource, Apache license, very well documented, simple to extend it, power design: with the concept of appender, you could build up your custom appender and use it to send logging data from remote customer computer to your head quarter using UDP protocol.
Try it, and let me know :-)
PS: the project seems to be discontinued, but it is mature and I'd used it without memory overload and cpu overhead problems.
The log4Delphi project has been dormant for 4 years but I have been granted access to update the dormant Log4Delphi project and I have rolled up 4 years of bugfixes and patches into the latest 0.8 release available on Source-forge. I use this library in production and have found it to very stable and reliable and easy to use.
Log4Delphi Downloads Page
I am attempting to use WinDBG or another debugger to debug a CodeGear Delphi 2007 Windows application on a remote machine. I have been unable to produce symbol files for WinDBG.
Is there a way to use WinDBG or another debugger to debug Delphi applications on a system that doesn't include the IDE?
Edit1
The remote debugger is not an option here. I am able to remote in to the end user PC, but I am unable to use the remote debugger due to firewall restrictions.
Edit2
I am able to remote in to the machine, but can not connect the CodeGear remote debugger due to firewall restrictions.
How about the remote debugger? Build your app with remote debug symbols and debug from your development machine across the network.
instead, i rely on MadExcept stack tracing and some logging features. my application is distributed worldwide & this has been sufficient.
You can try generating a map file and then convert it to a dbg file using map2dbg from
http://code.google.com/p/map2dbg/
Then you can load the dbg file in WinDbg.
Disclaimer: I had faced a similar issue but I managed to do remote debugging and didn't have to do all this. So I am not sure this will work. But if you try it then do let us know if it works.
I'm afraid this is one more of those "I don't have an actual answer" answers, but it might just help...
Have you considered adding logging to your application? I've heard great things about SmartInspect. With it, you can log all sorts of information, including stack traces and "watches" (variables).
Another logging product for Delphi is EurekaLog.
In Delphi you could use Run -> Attach to Process, select the remote machine and select the process you'd like to debug.
http://sourceforge.net/projects/tds2dbg/ can be used to convert Delphi's TDS debug files to DBG files. This gives basic symbol information -- functions, classes, units, but not variables. Enough for a reasonable call stack, and with a bit of knowledge, enough to debug Delphi apps live and with dumps.
I've written about some of Delphi+WinDBG experiences on my blog: https://marc.durdin.net/2015/11/windbg-and-delphi-a-collection-of-posts/
Thank you all for the great suggestions and interesting products.
To solve this specific issue, the "best" way I found uses the OutputDebugString located in the Windows namespace. This, along with Debug View from Sysinternals, will allow me to gather debug information and sort through it pretty quickly.
If you decide to use this method, make sure everything is wrapped in ANSI formatting. IE:
OutputDebugString(PAnsiChar(string1 + string2));
This makes sure that string1 and string2 are combined and then converted in to ANSI Characters.
I probably should have just started dumping text to a file for something quick and dirty, but this will allow a non-debugging version to emit debugging messages.
I'm finishing an internship at a company and have just been thrown onto this project for the last month where the program is built upon an engine that they "failed" to buy the source code for. Now I've been given the task of finding out why it is failing, on only certain conditions and customer feedback hasn't been great. The main developer for the project is also out on leave for several months.
I have the engine install and know the language it was written in (delphi6?).
note which I have never had to use
I have our products msi.
I'm expected to go through the regular app and pinpoint the problem. I suspect it is something to do with fields not being re-initialized properly.
Is there a way to attach a debugger to the exe to see callstacks and all that hotness?
Any help that would avoid countless use cases would be received gratefully.
You can attach the Delphi debugger to any running process (like all other win32 debuggers out there) but I don't think the experience will be near what you expect. Delphi produces really tight executables which means the info for building human readable callstacks or any kind of "hotness" are simply not there.
Your only chance is in that if your application is a Debug release. In that case, Delphi debugger should help more than a generic debugger.
You might also want to have a look at this thread - Is there a program to decompile Delphi?
In Delphi 2006 (not sure about 6) you can attach the debugger to a running process.
You only get assembler instructions, registers, flags, memory dump and stack (hex). Hope that is enough.
Nice, I tried to attach to the ide/debugger and they disallowed that ;-).