Reading Windows event logs

[ad...@docurated.com]

The golang.org/x/sys/windows package has a couple of functions for writing to Windows event logs, but none for reading it. I would like to add a few functions for reading event logs. The Go contribution guidelines encourage me to discuss my design prior to undertaking this, hence this message.

My plan is to add, at least, ReadEventLog and EvtQuery to the golang.org/x/sys/windows package. The former belongs to the Event Logging API, whereas the latter belongs to the Windows Event Log. Quoting MSDN, "The Event Logging API was designed for applications that run on the Windows Server 2003, Windows XP, or Windows 2000 operating system. In Windows Vista, the event logging infrastructure was redesigned." and "Windows Event Log is included in the operating system beginning with Windows Vista and Windows Server 2008."

Is there any reason these functions were not included in the library to begin with? Is there anything I need to know before forging ahead?

Thanks,

Adam

[Daniel Theophanes]

Writing to the windows event log was to support windows services which is common. I've never really had the need to query or otherwise reade the windows event log.

I'm not strictly opposed to adding them, but they may be better off in a third party package with a searchable description.

-Daniel

[brainman]

I agree with what Daniel said. I also don't see a benefit of adding 2 Windows APIs to golang.org/x/sys/windows - you still need to make them usable / easy to use for Go users.

Alex

[ad...@docurated.com]

Daniel and Alex,

Thank you very much for your replies! I'll make my code separate from golang.org/x/sys/windows.

Adam

[Matt Harden]

I thought the whole point of x/sys was to be a place for these direct system call mappings. They didn't have to meet some bar of usefulness to get in, unlike changes to the syscall package, which is covered by the Go 1 guarantee.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Theophanes]

Hi Matt,

If I take that to the logical extreme of not needing a bar of usefulness, everyone should put all their code in x/sys or similar. That probably isn't what you meant though.

The golang.org/x/... packages are not covered by the go1 compatibility promise, they are maintained by the go team in one way or another. As such there is a bar for package entry.

It is easy to write system call mappings. Here is one I use:

https://github.com/kardianos/osext/blob/master/osext_windows.go

The hard work isn't the syscall, but with the code that uses it.

-Daniel

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/E8E5sfTcboY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Matt Harden]

x/sys is specifically designated as a place for syscalls. No I would not suggest people put all their code in x/sys.

[pmo...@mozilla.com]

I would seem reasonable to me (as a complete novice) that all windows system api calls could be added.

i.e. if https://github.com/golang/sys/blob/1caf55eba1a755134294f972e0e17e5be7f67f8a/windows/syscall_windows.go#L85-L185 could be autogenerated from some structured output from the applicable functions defined under https://msdn.microsoft.com/en-us/library/

This is based on the following assumptions:
1) microsoft provide some structured data describing all their apis that can be consumed by a code generation process
2) the generated code does not need any modification - it is sufficient to consume windows api metadata from microsoft in order to make all system calls available via x/sys

I may be a bit out of my depth on this topic though - so please correct me if I am wrong or miss some key information. Obviously we don't want to burden the language with a higher maintenance cost - hence why I think it makes sense if it can all be auto-generated.

Pete

[pmo...@mozilla.com]

http://www.codeproject.com/Questions/203989/Header-file-to-use-Windows-api solution 2 seems to suggest that it is possible to download header files for the windows apis - would it be possible to parse these to auto-generate a complete set of syscalls in syscall_windows.go (link in previous message)?

Disclaimer: Apologies if I'm totally on the wrong track here!

[Daniel Theophanes]

The WinAPI is huge. Code isn't useful if it isn't tested with docs normally.

You may be interested in: http://godoc.org/github.com/lxn/walk and http://godoc.org/github.com/lxn/win

On Sat, Jun 20, 2015 at 1:49 AM <pmo...@mozilla.com> wrote:

http://www.codeproject.com/Questions/203989/Header-file-to-use-Windows-api solution 2 seems to suggest that it is possible to download header files for the windows apis - would it be possible to parse these to auto-generate a complete set of syscalls in syscall_windows.go (link in previous message)?

Disclaimer: Apologies if I'm totally on the wrong track here!

--

[brainman]

On Saturday, 20 June 2015 18:49:29 UTC+10, pmo...@mozilla.com wrote:
> ... would it be possible to parse these to auto-generate a complete set of syscalls in syscall_windows.go (link in previous message)?

Sure you could generate something like that. We used to do in runtime package - see defs_windows.go (it is not used at this moment) - for Windows data types and consts. Unfortunately it is not very useful for API calls - these need to present Windows errors similar to other functions in Go. How do you propose to handle Windows errors?

Alex

[durgabab...@vistarait.com]

Hi,

can any one provide the code to read/query event logs in golang?

thanks

[smt...@gmail.com]

Yes, anyone ?

13 Ocak 2016 Çarşamba 15:35:33 UTC+2 tarihinde Durgababu Neelam yazdı:

[Robert Engels]

Maybe this... https://grokbase.com/t/gg/golang-nuts/156jvs0e0p/go-nuts-reading-windows-event-logs

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Robert Engels]

Btw I know it is the beginning of the thread, but if you read through it, you will see what or how to do it. 

[Robert Engels]

I was referring to it because it lays out how to write the code to do it, or it appears the original poster has probably already written the code. WMI is a pain, lots of parsing. 

On Nov 7, 2018, at 9:51 AM, Samet Sazak <smt...@gmail.com> wrote:

Thank you for quick reply but it’s not related. I found elastic/beats using eventlog package but still didn’t solve the problem:) 

I will try WMI queries to get event logs.

Thanks,

--

Samet Sazak

[Samet Sazak]

Thank you for quick reply but it’s not related. I found elastic/beats using eventlog package but still didn’t solve the problem:) 

I will try WMI queries to get event logs.

Thanks,

On 7 Nov 2018 Wed at 18:03 Robert Engels <ren...@ix.netcom.com> wrote:

--

Samet Sazak

[Samet Sazak]

Thank you so much, I will ask to him.

--

Samet Sazak

[Samet Sazak]

By the way, I found this repository which is solved my problem :

https://github.com/0xrawsec/golang-evtx

Regards,

--

Samet Sazak