ok I checked in to this more deeply and I was wrong about a few things. first, my patch is worthless - there are several more instances where the retval of fileno is passed directly to fstat and that is totally valid (provided the file* points to a valid file).

looking deeper in the call stack, this call stack is originating from a PyCFunction_Call from mercurial's native extension, osutil.

 # Call Site
00 MSVCR90!fstat64i32+0xe8
01 python27!dircheck+0x29
02 python27!fill_file_fields+0x18e
03 python27!PyFile_FromFile+0x89
04 osutil+0x176f
05 python27!PyCFunction_Call+0x76

Here's the code in osutil.c (which is part of mercurial)

(osutil.c:554)
#ifndef IS_PY3K
	fp = _fdopen(fd, fpmode);
	if (fp == NULL) {
		_close(fd);
		PyErr_SetFromErrnoWithFilename(PyExc_IOError, name);
		goto bail;
	}

	file_obj = PyFile_FromFile(fp, name, mode, fclose); //this is the call that is the parent
	if (file_obj == NULL) {
		fclose(fp);
		goto bail;
	}

	PyFile_SetBufSize(file_obj, bufsize);
#else

fileno() is actually 'succeeding' and returning a value of 3.
fstat is then throwing the invalid parameter exception, presumably because 3 is not a valid file descriptor.
the way fileno() is implemented in M$CRT is really simple: it just copies a value at a fixed offset from the pointer passed to it without checking to see if the FILE* is valid.

this is why in the docs for _fileno they say "The result is undefined if stream does not specify an open file."

anyways, I don't think this is a bug in python, but rather in the mercurial extension.
it's a little tricky to debug on windows because the osutil module gets delay-loaded.
I'm taking another pass at it now.