Issues on work Windows 7 machine

[ndmitchell]

Given a work Windows 7 64bit machine, with 32bit cygwin and a nasty anti-virus, I tried running some commands from my user directory (C:\User\myusername), using a local file list.txt. Observations:

fsatrace foo.txt -- cmd /c "type list.txt"

This segfaults trying to write to a null pointer.

fsatrace foo.txt -- cat list.txt

This never completes. It spawns in infinite number of fsatracehelper.exe processes. As it spawns each one, they become suspended, and a new one is spawned. I had to kill them with taskkill /FI "IMAGENAME eq fsatracehelper.exe" /f, but if I didn't know taskkill it would have required a reboot.

I have VS2008 on my machine. Rebuilding got further if I removed the stdint.h headers, which aren't available on older versions and don't actually seem to be required. After that I got the errors:

hooks.c(59) : error C2065: 'FILE_DIRECTORY_FILE' : undeclared identifier
hooks.c(61) : error C2065: 'FILE_DELETE_ON_CLOSE' : undeclared identifier
hooks.c(105) : warning C4013: 'NT_SUCCESS' undefined; assuming extern returning
LINK : fatal error LNK1181: cannot open input file 'ntdll.lib'

Not sure if they are solvable or not - VS2008 is quite old now.

[ndmitchell]

Note all these tests were with the latest release, not the latest code.

[jacereda]

I've uploaded another binary distribution, this one should have better error checking. The errors you're seeing are easy to fix, but the linker error is more serious. I don't know in which library is NtQueryInformationFile() located when using the sdk that used to go with vs2008. I think you'll at least need vs2012 (the included build.bat is for vs2015).

You can also try with mingw, but that requires 2 compilers (64-bit, 32-bit).

[ndmitchell]

Trying the new binaries, both segfault after writing:

 r|C:\Users\myusername\list.txt

So it seeems to be a segfault during shutdown. If I can build with VS2008 I can debug it properly. Otherwise I'll try and reproduce on my machine tonight.

[jacereda]

When trying you might find helpful redirecting the output to stdout as:

fsatrace - -- cmd /c "..."

That should also rule out an error writing to the output file.

[ndmitchell]

Using - works perfectly, so it must be the output file.

[jacereda]

Does it crash if the output file doesn't exist?

[ndmitchell]

Yes. I get a crash if it exists, and if it doesn't exist.

[jacereda]

Nothing printed to stderr before crashing?

[ndmitchell]

Nope.

[ndmitchell]

In fact, just fsatrace foo.txt -- echo 1 crashes, and then there is very little on the console, so I am certain there is no stderr message.

[jacereda]

That echo is probably cygwin's. Does it crash with this one?

fsatrace foo.txt -- cmd /c dir

If I try your version I get an error printed complaining about CreateProcessW() (it can't find echo since it's a cmd.exe builtin).

[ndmitchell]

Yes, with cmd /c dir it crashes too. On my home desktop (Win 10) it works fine. Perhaps you could produce a binary where every other line was print something to stderr, and we can figure out which line it fails at?

Hopping into the debugger, I see unhandled exception, access violation writing to location 0 - so it seems like it should be relatively easy to track down. I didn't get any time today, but if I can build it with VS2008 I'll be able to hop into the debugger properly and see it almost immediately.

[ndmitchell]

Today (after a reboot), the same test has different behaviour, using the v0.2 binaries:

C:\Users\username>fsatrace  - --  cmd /c dir
Fatal: fsatrace.c:39: CreateProcessW(0, cmd, 0, 0, 0, CREATE_SUSPENDED, 0, 0, &si, &pi), err: 57

Trying the new binaries with fsatrace foo.txt -- cmd /c dir I get:

TlsFree(s_hooked)
UnmapViewOfFile(s_buf)
CloseHandle(s_mf)
GetExitCodeProcess(pi.hProcess, &rc)
CloseHandle(pi.hProcess)
0 != (of = CreateFileA(out, GENERIC_WRITE, 0, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_N
ORMAL, 0))
WriteFile(of, buf + 4, *(DWORD*)buf, 0, 0)

[jacereda]

In the first case, are we sure that cmd is \windows\system32\cmd.exe? What does

where cmd

say?

In the second case, looks like I made a mistake when checking the validity of the opened file (it should check against INVALID_HANDLE_VALUE). In that case, it would be an error opening the file. Can you perform that same test from %HOME%\Desktop?

[ndmitchell]

cmd is from System32, it's the normal Windows one.

I get the same results in %HOME%\Desktop, and it appears that the file worked just fine, as it does create foo.txt - it even has lots of lines in it - 912 bytes consisting of lots of copies of:

r|C:\workspace\bin\fsatracehelper.exe

[jacereda]

OK, got a windows box with vs2012 installed and I can reproduce it there. Looks like Windows7 requires the written parameter to be non-null. I'll upload a new build.

[ndmitchell]

Works now, thanks!