OK this is my problem.
I have a program lets name it Application_name.CGI file. It is a CGI that performs services for a web based application. The CGI is a PE executable written in Visual C. The file can be disassembled with IDA easily.
Now I want to debug it, tracing from early in the execution.

I can load it directly to Olly but the CGI requires a lot of parameters from the Web page that calls it and continues to exchange data with the web page all through its execution. When it is loaded by Olly, it it finds no input from the page, it closes right away.

I would like the web page that interacts with it (Which is local in my system)to be up and running, feeding it its data, when I am debugging it.
How can I catch it after the web page loads it? I've tried placing a spinning jump at the EP, but it crashes . . .

I have the impression this problem has a very simple solution. . .

Search before posting

Run it just like any other console program, but don't forget to set environment variables

naides, the first thing that came to mind for me was to set a break on the first windows function that it calls. Maybe a GetCommandLine kinda thing, or whatever the first windows function it calls it. Set that up, have the webpage fire it up, and as soon as it calls your targeted function in windows, BAM.

I got through TONS of DOS versions of Everlock because the idiots always put a call to int 21 to do something after all the decryption was done. It was always my way in.

@Litana: I know I can start it as a console, that is not the problem.
But without the data it gets from the web site, which is a large and cumbersome stream that I have not figured out how to capture and emulate, the CGI just quits very early in the execution, away form the interesting parts.

@Frank: Thank you for your suggestion. I'll have to fire SoftIce to do that in order to place global breakpoints. Olly only allows you to place BP in loaded or attached processes.

Some progress and a lot of weirdness.
I was finally able to trace into the CGI, by placing a JUMP EIP at the entry point and attaching Olly. BUT Olly seems to be on molasses when I trace it this way, taking 2 to 10 seconds per instruction.
If I trace it directly, form the console form, olly traces at normal speed. Any ideas?

Note: When the application is being traced this way, it is part of a Live website package, under the CGI interface. I don't know if this this is relevant.

Place jmp eip at the interesting parts?

This also happens to me when I attach to an arbitrary process with OllyDbg and try to debug it. It consumes 100% CPU. Hence I never use that feature and prefer to load directly.

P.S. standard input redirection is a good way to get the input into your app...

At least one little problem solved:
The Molasses holding back my Olly was in one way or another related to the presence of the Conditional Branch Logger Plugin.
I am not exactly sure why . . . I was not using the jump logger at all and had never used it with any of these CGI apps, so I doubt is the result of some UDD holdback.
As soon as I used a fresh copy of Olly without the plug-in, the debugging speed got up to normal.
Notice that the problem only arose when I attached to the CGI that had been launched from the Web page (by a Perl script). When I trace the CGI by directly loading it as a console app, I had no problems.

Something weird indeed.

Correction:
The problem was Not related to Conditional Branch Logger Plugin, directly, but to a number of plugins, but the most important actor causing the slow debugging problem was my FIREWALL.

The firewall (Outpost) It is particularly jealous of CGI scripts being run by iuser (Internet user): I used a second instance of Olly to watch Olly tracing the CGI in slow motion almost always landed on the threads running through the firewall's WL_HOOK.dll, which hooks (duh!) a number of APIs and surveys instances of an app reading or writing another process memory. So, if I deactivate the Firewall, I get normal tracing, regardless of plug-ins presence.

The firewall is more relaxed when I started the CGI from Olly, Because under those conditions, I am identified as a local admin/user, instead of a process being run by the "internet" iuser.

Sooo:
Firewalls, while indispensable in self defense for the main OS, can be quite invasive into the inner workings of the system and produce all sorts of surprises.
The simplest solution is the install the server app in a VM with a very basically configured OS and do all the debugging there

well not just cgi apps firewalls normally tend to frown upon anything
that modifies another process memory including debuggers

even the default windows firewall that comes with xp-sp2 will simply interfere with debugger performance especially while you set auto break points on a large numbers with scripts

its not just ollydbg that will come to crawl (it would atleast crawl) but windbg script will simply hang windbg gui if you set bp with scripts when a firewall is active