LogParser.exe

StrangeWill · Post by **StrangeWill** » Tue Apr 12, 2011 11:58 am

I was looking to migrate our Log Parsing setup to Linux, we parse windows event logs using Log Parser, yay lets try Wine!

Alas I'm stuck here:

Code: Select all


fixme:ntdll:NtQuerySystemInformation (0x00000032,0x32fad8,0x00000004,(nil)) stub
wine: Call from 0x7ef7dc26 to unimplemented function ntdll.dll.RtlCreateTagHeap, aborting

ntdll.dll is one that WINE overrides, and as I understand it, overriding WINE on that will just break WINE. Any ideas?

I'm running wine-1.1.42 on Debian.

StrangeWill · Post by **StrangeWill** » Tue Apr 12, 2011 12:00 pm

Err, no edit button?

I noticed Wine 1.2.x is out, would upgrading fix my DLL issue? I haven't found any documentation on ntdll.dll that says that has been added AFAIK.

Being as I'm on Debian... I'd have to compile from source, eh?

John Drescher · Post by **John Drescher** » Tue Apr 12, 2011 12:07 pm

Err, no edit button?

Check out the sticky. The reason is the forum gets sent to a mailing
list (which I am replying from). It would be very confusing if edits
were allowed on the forum to mailing list users..

I noticed Wine 1.2.x is out, would upgrading fix my DLL issue? I haven't found any documentation on ntdll.dll that says that has been added AFAIK.

I would try wine-1.3.X not 1.2.X and definitly not some earlier version.

Being as I'm on Debian... I'd have to compile from source, eh?

http://www.winehq.org/download/deblenny

John

StrangeWill · Post by **StrangeWill** » Tue Apr 12, 2011 12:16 pm

John Drescher wrote:Check out the sticky. The reason is the forum gets sent to a mailing
list (which I am replying from). It would be very confusing if edits
were allowed on the forum to mailing list users..

Oh, that's par for the course and I should have known that/read the sticky , my bad.

John Drescher wrote:http://www.winehq.org/download/deblenny

John

That's where I got my current version, which gave me 1.1.42, I'm working on building my own now to try and remedy this. Thanks.

StrangeWill · Post by **StrangeWill** » Tue Apr 12, 2011 1:48 pm

Alright, compiled 1.3.17 from source, same error.

http://source.winehq.org/WineAPI/ntdll.html

Shows:

RtlCreateTagHeap (stub)

I'm assuming by stub we mean not implemented?

StrangeWill · Post by **StrangeWill** » Wed Apr 13, 2011 8:38 am

Ok, so an update in case anyone stumbles across this.

I've decided to start removing stubs and putting placeholders in my branched code, seeing what other methods I need... if I needed just RtlCreateTagHeap I'd just write it... right?

Oops wrong.

First, RtlCreateTagHeap isn't documented like RtlCreateHeap is, so to implement it is going to be a pain, even other libraries that have RtlCreateTagHeap in them have them as stubs...

Secondly, if I replace the stub so it acts implemented, I get this:

Code: Select all

fixme:ntdll:NtQuerySystemInformation (0x00000032,0x32fb28,0x00000004,(nil)) stub
wine: Call from 0x7bc4d670 to unimplemented function ntdll.dll.RtlGetNativeSystemInformation, aborting

So I'm pretty much looking at having to implement a good chunk of NtQuerySystemInformation for WINE, and I can't even begin to guess how deep this rabbit hole goes. Worse yet this has a stub, but is commented out, I wonder why.

And again, RtlGetNativeSystemInformation seems to be another piece of API that doesn't have documentation the public can access, and because of this I'm having massive problems implementing a placeholder to see how much of ntdll.dll would have to be written for this one program...

So barring anyone having suggestions on this, the command line utility LogParser.exe on WINE is a no go unless a lot of undocumented library calls are basically reverse engineered?

James McKenzie · Post by **James McKenzie** » Wed Apr 13, 2011 9:45 am

On Wed, Apr 13, 2011 at 6:38 AM, StrangeWill <[email protected]> wrote:

Ok, so an update in case anyone stumbles across this.

I've decided to start removing stubs and putting placeholders in my branched code, seeing what other methods I need... if I needed just
RtlCreateTagHeap I'd just write it... right?

If only it were that easy, there would be much more of the WindowsAPI
implemented. That has been said by many in the Wine Development list
(where this is much more on topic.)

Oops wrong.

First, RtlCreateTagHeap isn't documented like RtlCreateHeap is, so to implement it is going to be a pain, even other libraries that have
RtlCreateTagHeap in them have them as stubs...

Welcome to the Microsoft method of documentation. I've run into this
with several simple to implement processes.

[snip]

So I'm pretty much looking at having to implement a good chunk of NtQuerySystemInformation for WINE, and I can't even begin to guess how deep
this rabbit hole goes. Worse yet this has a stub, but is commented out, I wonder why.

Don't know about the comment out of the stub, but to find out how deep
the rabbit hole is when you 'chase the rabbit'. It could be very deep
or you could find that all you have to implement is this function.

And again, RtlGetNativeSystemInformation seems to be another piece of API that doesn't have documentation the public can access, and because
of this I'm having massive problems implementing a placeholder to see how much of ntdll.dll would have to be written for this one program...

Some of these functions are documented, just not by Microsoft.

So barring anyone having suggestions on this, the command line utility LogParser.exe on WINE is a no go unless a lot of undocumented library
calls are basically reverse engineered?

Reverse engineered == bad, bad, bad. Black Boxed is much better. If
you can figure out what are the inputs then you can test away. Maybe
those are documented somewhere and you will have to observe what is
inputted to the process and what is outputted. There is a whole Wiki
worth of development information on what is and is not allowed for
Wine development. Looking at any Microsoft code or derivative is an
absolute no-no.

James McKenzie

vitamin · Post by **vitamin** » Thu Apr 14, 2011 8:34 pm

StrangeWill wrote:I was looking to migrate our Log Parsing setup to Linux

What exactly are you trying to do? What logs are you parsing? From where? How are they being transferred? Using what software?

StrangeWill wrote:fixme:ntdll:NtQuerySystemInformation (0x00000032,0x32fad8,0x00000004,(nil)) stub

0x00000032 is SystemRangeStartInformation? that's something really undocumented...

StrangeWill · Post by **StrangeWill** » Wed Apr 20, 2011 11:22 am

vitamin wrote:
StrangeWill wrote:I was looking to migrate our Log Parsing setup to Linux
What exactly are you trying to do? What logs are you parsing? From where? How are they being transferred? Using what software?

Windows event logs, querying remotely from Linux, ended up writing a Java application using WMI, but it's too slow (WMI is, not Java...), so I'm still kind of dead in the water, and looking at Windows RPC API implementations and WINE again.

StrangeWill wrote:fixme:ntdll:NtQuerySystemInformation (0x00000032,0x32fad8,0x00000004,(nil)) stub

0x00000032 is SystemRangeStartInformation? that's something really undocumented...[/quote]
Yeah, I have absolutely no idea how LogPaser accesses the log files, hopefully it isn't trying to do it through RPC, or any attempts at a custom coded application on WINE is also going to be in vein.

vitamin · Post by **vitamin** » Fri Apr 22, 2011 8:42 am

StrangeWill wrote:Windows event logs, querying remotely from Linux

That won't work. All such functionality is missing from Wine.

LogParser.exe

LogParser.exe

LogParser.exe

Re: LogParser.exe

LogParser.exe

Re: LogParser.exe

Re: LogParser.exe

Re: LogParser.exe