I want to zip a file within a thread using the TZipMaster component.
The problem is, when I run the program from the IDE I get the error
(from windows)
"the program doesn't respond anymore.
-> Search online for a solution
-> Close program"
(or somehting like that I don't know the exact message in english.."
However, the ZIP files are created succesfully.
The last debugger output from Delphi 2009 is:
unload module: DelZIp179.dll
When I run the .exe directly, it seems to work fine and I don't get this error.
However I'm not sure if I can just ignore this error or it's better to fix it?
Thanks for you replies!
You get this error because your application is doing some heavy processing (zipping) in the main thread and is not processing Windows messages.
It is better to fix this - either you should process Windows messages while zipping (if TZipMaster supports that) or move zipping into background thread.
More info:
I inspected the TZipMaster source and there's a OnTick event which gets called periodically.
Write a OnTick event handler and call Application.ProcessMessages from inside. That should remove your problem.
Related
Found this this post ISAPI web application hanging if FastReport.PrepareReport is called
It helped solving my problem partially. As well I´ve turned Wisiyng property to False on frxRichView. Since I'm retunrnig a base 64 string I've also tryed switched loading from StrToStream/LoadFromStream to LoadFromFile. The problem persist with multiple acess, 2 out of 10 process can finish loading my Pdf file. All the others requests hangs until timeout. Does anyone have an idea what else can I do? is there anyother way to retunr rtf format into Fastreport report Thanks.
I could only get time-out error using Selenium to test multiples request from the client side.
Update: I've figured that just having a TfrxRichView component in the report causes the hanging, it doesn't even need to have a rtf text on it. Replacing it to a memo all request are answered.
UPDATE: Got a answer from fast report and I wold like your opinion.
ok,
I had similar problems, and it is not easy to find out the reason, but maybe you can find your solution in between my considerations..
1) Stack Size
When ran in IIS your ISAPI is only a DLL called by a process, you are not the main process so you have to pay attention to stack dimension.
Normally a Delphi application have a default stack size of 1Mb, in ISAPI DLL you will have only 256Kb of stack.
Maybe you are facing a stack overflow exception.. it can explain why it does not occurr always but only in some circumstances..
2) Trapped Exception
In general you get some error during the preparation of report (aka all the job of working with data, expressions, variables, formulas etc etc..) can bring to a trapped exception. You may be unable to see it from outside but code execution was broken somwhere and report preparation had not finished.
3) MessageBoxes and/or standard Exceptions
when running in ISAPI you should not output anything to user interface,
maybe a message dialog (or an exception) can bring to unexpected behaviour.
4) Global Var
You should avoid global var because in ISAPI they will be common across threads
So, if you have sources, debug the application.. at first exception you should understand where is your problem..
If you have not sources.. chek the above list.. I hope you can find some useful information.
You have two ways to solve this:
1- Try to recreate this behavior while debugging your ISAPI DLL. If you are lucky, you can identify the thread that is hanging your application. Sometimes this is hard or even impossible to recreate.
2- If you have access to the hung ISAPI application instance, use a tool like SysInternals Process Explorer to create a minidump file. Your application must be built using full debug symbols and you should have the corresponding map file. With one (or more - even better) dump files obtained from your hung application plus the map file, you can use another tool, WinDbg to analyze it and find the cause. (Sometimes) WinDbg can show exactly which thread is hanging the whole application and the line of code that causes it.
If you have never done that, I must warn you that this kind of analysis is almost a gamble... You have to use several different tools with little
or no documentation, read heaps of technical info in various places. In the end, sometimes it works wonderfully and sometimes it fails miserably.
Because debugging ISAPI is not obvious, but also because I wanted to be able to switch easily between more different hosting solutions — and wanted to update my website on the fly without a restart of the web-server/service — I created xxm. It has a singular interface to the HTTP context, your DLL gets loaded by either a IIS ISAPI handler, or a HTTP.SYS handler, or an Apache httpd module, or for debugging locally you can just set xxmHttp.exe as host application to get IIS out of the way.
Is there any way to delete a file when its using by any program or other process in windows?
I searched and found this 2 ways:
1- using RunOnce key in Registry;
I'm not gonna use this because i dont want to wait for windows restart or anything else... prefer to do it ontime!
2- using the way declared in this page: http://www.delphipages.com/forum/showthread.php?t=201190
the problem here is its useful under NT windows, i need a way works on all Windowses!
Thank you.
the problem here is its useful under NT windows, i need a way works on all Windowses!
All modern desktop Windowses (XP, Vista, 7) are also NT. Do you really need to work with NT<4 or Win98? Or even Win CE/Mobile/Phone? Probably not.
If you need to delete an open file straight away, about the only thing you can do is attach to each process using debugger privileges, see if it has any handles open on the file, and if so close them underneath it. You can do this the manual way using eg Process Explorer. Many applications won't react well to having their files closed on them; expect them to exception out when they try to do something with the dead handle.
Unfortunately there is no option in Windows to have Unix-style files that can exist attached to a file handle independently of being stored under a filename on disc.
You cant delete a file when someone is using it. No matter how hard you try, windows will not let you. It can work with some files, but in general it does not work.
What you can try is postpone the deletion, when no one is using the file. You can:
1 - use RunOnce, but you dont want that.
2 - Wait in a loop, trying to delete the file. Pseudo code:
DeleteFile
Check if you was able to delete or if file still exists.
if you are able to delete, then exit loop.
That is the best you can do, and what i could remeber.
Try MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT flag. Will postpone move or delete action until reboot.
Edit:
If you don't whant to restart the only option is to close those handles. ProcessExplorer does that and works all the time and I have not seen any process to crash. See more info about enumeration handles in a process at
http://www.codeguru.com/forum/archive/index.php/t-176997.html. But keep in mint that you should enumerate all processes in the system and behave different on Vista+ (you need to be elevated)
Your files are most likely locked because some process has a handle open to them. That is the most common reason for the Access denied result when deleting or moving a file.
A really blunt way is to close that handle.
Then Handles tool from SysInternals (you can download the sources too) can do that for you: I have been successfully using that.
Note 1: You need administrative privileges to use it.
Note 2: Closing a handle from another process is considered very rude, and can make that process unstable.
A very simple situation. I'm working on an application in Delphi 2007 which is often compiled as 'Release' but still runs under a debugger. And occasionally it will run under SilkTest too, for regression testing. While this is quite fun I want to do something special...
I want to detect if my application is running within a debugger/regression-tester and if that's the case, I want the application to know which tool is used! (Thus, when the application crashes, I could report this information in it's error report.)
Any suggestions, solutions?
You can check the parent process that started your application.
With CreateToolhelp32Snapshot/Process32First/Process32Next get the parent PID (PROCESSENTRY32.th32ParentProcessID or TProcessEntry32.th32ParentProcessID) for your application PID. Then get the filename for the parent PID to compare with the applications you want to check for, like SilkTest.
Check this article for code usage.
In addition to IsDebuggerPresent and CheckRemoteDebuggerPresent, you can also query PEB.BeingDebugged (PEB is Process Environment Block, to get PEB you must query TEB, which is the Thread Enviroment Block).
You're probably looking for the IsDebuggerPresent function.
To detect SilkTest, you could try to attach to a DLL which is used only by SilkTest in order to detect its presence. For example, if the Open Agent is attached to a process, Win32HookDll_x86.dll or Win32HookDll_amd64.dll will be present (the names can be easily found out with a tool like Process Explorer.
You can also do
if DebugHook <> 0 then ...
This question already has answers here:
Can one executable be both a console and GUI application?
(9 answers)
Closed 6 years ago.
Is it possible to (and if so, how do I) make a single program work both as a console application and a GUI version using Delphi 2007?
What I am after is that if the program is run with the appropriate command-line options, it should function as a console program, printing output to the console using WRITELN, but if no command line arguments are given it should run as a normal Delphi GUI application?
The catch is that when running as a console application, the command line interpreter waits for the application to terminate before allowing you to enter a new command, whereas a GUI application started from the command line immediately returns you to the command line and the GUI application is started in a detached process. I want this behaviour retained.
I don't mind something like this:
IF GUI THEN StartApplicationAsGUI(ParamStr(0))
ie. I don't mind that I'll have to restart the application using some form of EXECUTE call to start it in GUI mode if needed, as long as the command line interface returns to the command line input when the GUI version is started.
I'd prefer a solution/suggestion that is along the lines of:
<Parse Comnand Line>
IF ConsoleMode THEN
RunConsole(Parameters)
ELSE BEGIN
Application.Initialize;
Application.CreateForm(...)
Application.Run;
END
(or vice-versa, ie. doing things a special way if GUI mode)
so that I can still use Delphi's IDE and VCL when making the GUI interface...
On Windows this is a little bit tricky. Actually the distinction between a console application and a GUI one is a single flag in the PE header. You can easily write console applications that create windows but that way you always have the console window around (you could hide it, though, but that wouldn't be nice when people run your program from cmd).
You can, however write a GUI application that creates a console if it needs to, using the AllocConsole function:
A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console.
If the calling process creates a child process, the child inherits the new console.
AllocConsole initializes standard input, standard output, and standard error handles for the new console. The standard input handle is a handle to the console's input buffer, and the standard output and standard error handles are handles to the console's screen buffer. To retrieve these handles, use the GetStdHandle function.
This function is primarily used by graphical user interface (GUI) application to create a console window. GUI applications are initialized without a console. Console applications are initialized with a console, unless they are created as detached processes (by calling the CreateProcess function with the DETACHED_PROCESS flag).
However, when run from cmd this will likely cause another console window to appear instead of re-using the existing one. I don't know whether a good solution exists there.
IMO, the best approach here is to have non-visual classes that actually do the work of the program. Then you can call that from a GUI program, and you can also call it from a separate command line program. Both programs are just wrappers around the functionality of your class(es).
This forces the design to be clean too - your classes necessarily are separated from the GUI layer of your application.
http://blogs.msdn.com/oldnewthing/archive/2009/01/01/9259142.aspx
Windows has different values in executable's header for console and UI application (see more details here). So it seems to be impossible to make the same executable to work in both modes.
As an alternative, you can open a console in you UI app, but it will be new console, not the one you've started app from.
AttachConsole() may be used to get a hold of the parents console.
E.g. if the application is started from a cmdline shell, AllocConsole() can be avoided:
if not AttachConsole(ATTACH_PARENT_PROCESS)
then AllocConsole;
More info here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681952(v=vs.85).aspx
I have a windows service that is failing to start, giving an error "Error 1053: The service did not respond to the start or control request in a timely fashion".
Running the service in my debugger works fine, and if I double click on the the service .exe on the remote machine a console window pops up and continues to run without problem - I can even see log messages showing me that the program is processing everything the way it should be.
The service had been running fine previously, though this is my first time, personally, trying to deploy it with the most recent changes made to the program. I've evaluated those changes and cant figure out how they might cause this problem, particuarly since everything runs fine when not started as a service.
The StartRoutine() method of the service impelmentation is empty, so should be returning in a "timely fashion".
I've checked the event logs on the computer, and it doesn't give any additional information other than it didn't hear back from the service in the 30 second requisite time frame.
Since it works on my machine, and as a double-clicked executable, how would I go about figuring out why it fails as a service?
Oh, and it's .NET 2.0, so it shouldn't be affected by the 1.1 framework bug that exhibited this symptom (http://support.microsoft.com/kb/839174)
The box is a windows server 2003 R2 machine running SP2.
This is a misleading error. It's probably an unhandled exception.
Empty your OnStart() handler then try this in your constructor...
public MainService()
{
InitializeComponent();
try
{
// All your initialization code goes here.
// For instance, my exception was caused by the lack of registry permissions
;
}
catch (Exception ex)
{
EventLog.WriteEntry("Application", ex.ToString(), EventLogEntryType.Error);
}
}
Now check the EventLog on your system for your Application Error.
Could be a number of things and it might help to get a stack trace on the machine exhibiting the problem. There are a number of ways to do this but the point is that you have to see where this is failing in the code.
You can do this with remote debugging, but a simple thing might be to just log to the event logger, or file log if you have that. Literally, putting "WriteLine("At class::function()") throughout portions of the code to see if you've made it there.
This will at least get you looking in the right direction (which ultimately is the code).
Update:
See Microsoft's How to Debug Windows Services article for details in troubleshooting startup problems using WinDbg.
This related question details nice ways to debug services that are written in .NET.
I agree with Scott, the easiest way to find out what's happening is to put some traces in the start-up code (maybe it doesn't even come to your start-up code).
If this doesn't help, you can post your code here so others can take a look.
perhaps lacking some dependence, try this :
- deregister your service
- register again
If fail at register means that lack an module.
If the StartRoutine is empty, you are probably starting it somewhere else.
IIRC you need to fire off a worker thread, and then return from StartRoutine.
One of the problems which may lead to this error is if windows service which needs to be deployed consists of some error i.e it may be simple authorization error or anything as in my case I have referenced some folders and files for logging which were not existing, but when provided the right path of those file and folders it solved my problem.
I ran through every post on this particular subject and none of the responses solved the problem, so I'm adding this response in case this helps someone else. Admittedly this only applies to a new service, not this specific case.
I was writing a File listening service. As a console app, it worked perfectly. When I ran it as a service, I got the same error as above. What I didn't know (and many of the MSDN articles about services conveniently leave out) is that you need to have your class executed from within ServiceBase.Run( YourClassName());. Otherwise, your app executes and immediately terminates and because it terminated, you get the error above even if no error or exception occurred. Here is a link to an article about this. It actually discusses setting up your app for dual use - Console app and service: Create a combo command line / Windows service app
I had that issue and the source of my problem was config file. I edited it in notepad and notepad added one special character which cause service not to run properly because config file was ruined. I saw that special character in notepadd++ and after delete it, service started to run successfully as previous did.
In my case, the correct .NET framework was not installed on the server that I was installing the Windows service on.
One other reason is If you copy the DLL in 'debug' mode to installation folder this issue will come.What you need to do is Run the project in 'Release' mode copy the DLL or directly form Release folder rather than Debug folder,,and copy that DLL in to installation folder,it will work.You can see the reduction in size of DLL ,it will not contain any debug symbols and like that