Win-based FTP server stack overflow, /GS, safeSEH?

[drunken_chin () yahoo com]

Despite their decreasing presence, and my critical lack of experience, I am trying to learn more about typical C and 
C++ memory corruption techniques and have found an apparent pre-auth stack overflow in an obscure FTP server. The app 
appears to be compiled with a recent version of Visual Studio, evidently using /GS and perhaps SafeSEH as well. I had 
no joy doing anything other than a DoS with XPSP2 and have moved backwards to a Win2K system, but am still having 
trouble getting anything other than a DoS. Anyone who has time/interest in helping with this, I'd appreciate it. 
Details:

Buffer of 17500 A's generates the "Buffer overflow detected!" message. Since the app/windows handles the exception, 
setting Olly to intercept doesn't work, so I've attached to the process after the overflow takes place.

I've apparently found my buffer in the stack of the main thread:

00127000   00009000            00030000                           stack of main thread        Priv   RW  Guarded      RW

0012FC2C  008F6E01  ASCII "AAAAAAAAAAAAAA".... (repeats)

The section of memory where this stack is located is marked "RW Guarded", so I assume this stack is non executable, by 
nature of the compiler options, not the OS - is that correct? I didn't think Win2K had the option to use a nonexec 
stack within the OS.

No matter where I seem to go as I fumble about with Olly, I am not finding where my buffer is overwriting any of the 
registers (looking for EIP of course, but something leading towards EIP would be nice). If it's not landing on a 
register, what else might it be hitting? (more research required)

It was suggested to me to lengthen the fuzzer buffer and look for an SEH pointer overwrite, but from what I can tell, 
that's not happening either. I probably just don't really know where to look, but every SEH value that I inspected no 
matter how large I increased the buffer did not contain any portion of my A chars. Could this be due to safeSEH 
compilation options? My limited reading makes me think that if this is compiled with /GS, and with SafeSEH, I might as 
well give up this approach and simply report to the vendor as a DoS.

I've done a small bit of tracing to watch how things flow into NTDLL, and USER32 as this takes place, and have done 
some backtracing but I'm obviously missing something (not a big suprise).

How can I tell from the binary if it was compiled with SafeSEH? Someone mentioned to me how you can detect /GS (which 
I've forgotten), but I don't know about SafeSEH.