"Snap In" missing.

When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?

Peter Jason wrote:
When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?

MMC
^ ^ ^
| | |
| diskmgmt.msc
|
eventvwr.msc

The thing on top, manages the snapins and is basically
a place for a lot of Administrator functions.

And the error code, is perfectly useless.

https://airbrake.io/blog/dotnet-exce...ationexception

Does this require being a member of the Adminstrators Group ?

*******

On the system I'm sitting at, there is eventvwr.exe
and eventvwr.msc. The .msc is an XML file. This is
just a tiny portion I copied out.

ComponentDatas
ComponentData
GUID Name="Snapin"{975797FC-4E2A-11D0-B702-00C04FD8DBF7}/GUID
Stream BinaryRefIndex="4"/
/ComponentData
/ComponentDatas
Components
Component ViewID="2"
GUID Name="Snapin"{975797FC-4E2A-11D0-B702-00C04FD8DBF7}/GUID
Stream BinaryRefIndex="5"/
/Component
/Components

And the funny thing is, the .msc (text file) is bigger
than the EXE.

I wonder if some service has to be running for it to work ?

For example, in a quick Google, they mention an Event Viewer Service.
Which seems a bit weird.

It suggests the MMC part is just the "console" or "viewing part".
There are other bits underneath to make it function and actually
use the graphical window.

If you know the filenames of the thing you're working
on (eventvwr), it should be easy to track down some
of the components. The Event Viewer Service, services can
have file names quite different than the name of the service.
Microsoft does that to make the whole experience more fun.

You can use Process Explorer to query a few things on your system
and track down their origins. Running Process Explorer as
Administrator, makes a few more of the low-level constructs visible.
Sometimes you can even coax a filename out of it.

You're going to have to hark back to your last BlackViper
session when you were disabling services, to get things
running again :-)

Paul

"Peter Jason" wrote in message
...

When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?


This may help:

http://troubleshooter.xyz/wiki/fix-m...e-the-snap-in/
--
Bob S.

Peter Jason wrote:

Where can I get this "Snap In"?

You've already got the snapin (lots of them *.msc) but it's crashing.

I've not seen it for several years but probably a corrupt event log
file, try clearing it, it used to be simple when there were only three
per machine, now there are hundreds of them.

"Peter Jason" wrote in message
...

When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?


Below is bat file you can use to clean out the logs as someone else
suggested. Copy it into Notepad and save it as Clean.bat to your desktop -
be sure it doesn't have the .txt extension. Then right-click and select
"Run as Administrator". It will open a command window and you will see all
the logs being cleaned out.

Maybe it will help - maybe not.
--
Bob S.

"Bob_S" wrote in message news

"Peter Jason" wrote in message
.. .

When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?


Below is bat file you can use to clean out the logs as someone else
suggested. Copy it into Notepad and save it as Clean.bat to your desktop -
be sure it doesn't have the .txt extension. Then right-click and select
"Run as Administrator". It will open a command window and you will see all
the logs being cleaned out.

Maybe it will help - maybe not.

And now for the secret sauce I forgot to paste in.....

@echo off
FOR /F "tokens=1,2*" %%V IN ('bcdedit') DO SET adminTest=%%V
IF (%adminTest%)==(Access) goto noAdmin
for /F "tokens=*" %%G in ('wevtutil.exe el') DO (call :do_clear "%%G")
echo.
rem echo goto theEnd

:do_clear
echo Clearing %1
wevtutil.exe cl %1
goto :eof
:noAdmin
exit

Bob S.

Bob_S wrote:
"Bob_S" wrote in message news

"Peter Jason" wrote in message
...

When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?


Below is bat file you can use to clean out the logs as someone else
suggested. Copy it into Notepad and save it as Clean.bat to your
desktop - be sure it doesn't have the .txt extension. Then
right-click and select "Run as Administrator". It will open a command
window and you will see all the logs being cleaned out.

Maybe it will help - maybe not.

And now for the secret sauce I forgot to paste in.....

@echo off
FOR /F "tokens=1,2*" %%V IN ('bcdedit') DO SET adminTest=%%V
IF (%adminTest%)==(Access) goto noAdmin
for /F "tokens=*" %%G in ('wevtutil.exe el') DO (call :do_clear "%%G")
echo.
rem echo goto theEnd

:do_clear
echo Clearing %1
wevtutil.exe cl %1
goto :eof
:noAdmin
exit

Bob S.

It looks like the log files are here, and
one for each logging area. At first I was concerned
this was stored in a .edb (which would mean more
complications for cleanup).

C:\Windows\System32\winevt\Logs

The files, if you right click, appear to be bound
to a "snapin launcher", which just looks like some
sort of App (Metro) invocation.

Event Viewer Snapin Launcher

C:\WINDOWS\system32\eventvwr.exe.FriendlyAppName === An App ???

*******

The file format is here. And visually, isn't
all that pleasing, as the double-byte characters
aren't "switched on" by any sort of global declaration.
(No BOM at the beginning of the file to make it
readable easily by humans.) You'd swear the file
was binary when looking at it.

https://github.com/libyal/libevtx/bl...EVTX).asciidoc

This looks like this program may read the "raw"
event files (EVTX), as the comments on this web page
mention making a shadow of C: before attempting to
access the files. Since the files are in constant usage,
you'd expect some sort of complications to getting at
them. My guess is, this gives another view of the
contents of the files. Since it's making a shadow,
or claims to be, the list of events in the window
should not update in real time. You'd need to stop
the program and start the program again, to get
the latest view of events.

https://www.nirsoft.net/utils/full_event_log_view.html

Paul

"Paul" wrote in message news

Bob_S wrote:
"Bob_S" wrote in message news

"Peter Jason" wrote in message
...

When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?


Below is bat file you can use to clean out the logs as someone else
suggested. Copy it into Notepad and save it as Clean.bat to your
desktop - be sure it doesn't have the .txt extension. Then right-click
and select "Run as Administrator". It will open a command window and
you will see all the logs being cleaned out.

Maybe it will help - maybe not.

And now for the secret sauce I forgot to paste in.....

@echo off
FOR /F "tokens=1,2*" %%V IN ('bcdedit') DO SET adminTest=%%V
IF (%adminTest%)==(Access) goto noAdmin
for /F "tokens=*" %%G in ('wevtutil.exe el') DO (call :do_clear "%%G")
echo.
rem echo goto theEnd

:do_clear
echo Clearing %1
wevtutil.exe cl %1
goto :eof
:noAdmin
exit

Bob S.

It looks like the log files are here, and
one for each logging area. At first I was concerned
this was stored in a .edb (which would mean more
complications for cleanup).

C:\Windows\System32\winevt\Logs

The files, if you right click, appear to be bound
to a "snapin launcher", which just looks like some
sort of App (Metro) invocation.

Event Viewer Snapin Launcher

C:\WINDOWS\system32\eventvwr.exe.FriendlyAppNam e === An App ???

*******

The file format is here. And visually, isn't
all that pleasing, as the double-byte characters
aren't "switched on" by any sort of global declaration.
(No BOM at the beginning of the file to make it
readable easily by humans.) You'd swear the file
was binary when looking at it.

https://github.com/libyal/libevtx/bl...EVTX).asciidoc

This looks like this program may read the "raw"
event files (EVTX), as the comments on this web page
mention making a shadow of C: before attempting to
access the files. Since the files are in constant usage,
you'd expect some sort of complications to getting at
them. My guess is, this gives another view of the
contents of the files. Since it's making a shadow,
or claims to be, the list of events in the window
should not update in real time. You'd need to stop
the program and start the program again, to get
the latest view of events.

https://www.nirsoft.net/utils/full_event_log_view.html
Paul

Paul,

For almost all of the logs, they are overwritten (circular logs) so they
will be cleared with the above script which is easily tested and you can
then open the Event Viewer and see the logs have been cleared except for the
debug and analytic logs which can be cleared manually. If you run the
script, one of the the very first entries tells you the debug log can't be
cleared. If you open a PowerShell command (admin rights) and paste this in:

wevtutil el | Foreach-Object {wevtutil cl "$_"}

you will see the message about the channel being an "Enabled direct channel"
which first must be disabled - (e.g. made to be a circular log or manually
cleared).

The script does not force any log to have a shadow copy made since most are
circular logs and are always being overwritten.

I'm not a deep diver when it comes to researching the intricacies of Windows
these days. I need enough info to get things fixed, back up and running.
The detail you provide in your replies shows that you are certainly detail
oriented - most likely because your past or present work require that depth
of research.

I'm not interested in knowing what a virus / malware did to the system. It's
broke - fix it the fastest way possible. With the complexity of software
and operating systems today (as you just demonstrated using a simple log
cleaning as an example), I can do a reimage of a system a lot faster and get
the client back up and running.

However, having said that, I do not mean I do not go diving into the logs to
try and get a clue as to what the hell went wrong - hardware or software
wise. But as you also know, the error codes, log comments and other listing
data found in them are subject to many inaccuracies leading you down the
deep bunny hole to nowhere. So it's the hardware logs that get a quick
look, security and the Admin level logs and if I can't get a clue by then,
then it's time to just fix it and worry about what happened at a later time.

Clients don't like paying for "research" time. Think of a PC as being
modular. A drive crashes, you replace it. A monitor goes up in smoke -
again you replace it. Same for the software - reimage or reload. Yes, I
would like to know what happened and learn from it if possible but the
client only wants to know "Is it fixed - yet?"

We have two distinct approaches to getting a system back up and running.
Yours is a great teaching tool method, mine is more "Do this and never mind
why". Your approach is definitely more suited to teaching than mine - no
doubt about it. That comes from 20 years in the AF and working with FAA
keeping systems up and running at all costs when aircraft are depending on
those ground systems. Fix it - worry about why later....

So keep digging - we're all reading.....

--
Bob S.

Bob_S wrote:
"Paul" wrote in message news

Bob_S wrote:
"Bob_S" wrote in message news
"Peter Jason" wrote in message
...

When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?


Below is bat file you can use to clean out the logs as someone else
suggested. Copy it into Notepad and save it as Clean.bat to your
desktop - be sure it doesn't have the .txt extension. Then
right-click and select "Run as Administrator". It will open a
command window and you will see all the logs being cleaned out.

Maybe it will help - maybe not.

And now for the secret sauce I forgot to paste in.....

@echo off
FOR /F "tokens=1,2*" %%V IN ('bcdedit') DO SET adminTest=%%V
IF (%adminTest%)==(Access) goto noAdmin
for /F "tokens=*" %%G in ('wevtutil.exe el') DO (call :do_clear "%%G")
echo.
rem echo goto theEnd

:do_clear
echo Clearing %1
wevtutil.exe cl %1
goto :eof
:noAdmin
exit

Bob S.

It looks like the log files are here, and
one for each logging area. At first I was concerned
this was stored in a .edb (which would mean more
complications for cleanup).

C:\Windows\System32\winevt\Logs

The files, if you right click, appear to be bound
to a "snapin launcher", which just looks like some
sort of App (Metro) invocation.

Event Viewer Snapin Launcher

C:\WINDOWS\system32\eventvwr.exe.FriendlyAppName === An App ???

*******

The file format is here. And visually, isn't
all that pleasing, as the double-byte characters
aren't "switched on" by any sort of global declaration.
(No BOM at the beginning of the file to make it
readable easily by humans.) You'd swear the file
was binary when looking at it.

https://github.com/libyal/libevtx/bl...EVTX).asciidoc


This looks like this program may read the "raw"
event files (EVTX), as the comments on this web page
mention making a shadow of C: before attempting to
access the files. Since the files are in constant usage,
you'd expect some sort of complications to getting at
them. My guess is, this gives another view of the
contents of the files. Since it's making a shadow,
or claims to be, the list of events in the window
should not update in real time. You'd need to stop
the program and start the program again, to get
the latest view of events.

https://www.nirsoft.net/utils/full_event_log_view.html
Paul

Paul,

For almost all of the logs, they are overwritten (circular logs) so they
will be cleared with the above script which is easily tested and you can
then open the Event Viewer and see the logs have been cleared except for
the debug and analytic logs which can be cleared manually. If you run
the script, one of the the very first entries tells you the debug log
can't be cleared. If you open a PowerShell command (admin rights) and
paste this in:

wevtutil el | Foreach-Object {wevtutil cl "$_"}

you will see the message about the channel being an "Enabled direct
channel" which first must be disabled - (e.g. made to be a circular log
or manually cleared).

The script does not force any log to have a shadow copy made since most
are circular logs and are always being overwritten.

I'm not a deep diver when it comes to researching the intricacies of
Windows these days. I need enough info to get things fixed, back up and
running. The detail you provide in your replies shows that you are
certainly detail oriented - most likely because your past or present
work require that depth of research.

I'm not interested in knowing what a virus / malware did to the system.
It's broke - fix it the fastest way possible. With the complexity of
software and operating systems today (as you just demonstrated using a
simple log cleaning as an example), I can do a reimage of a system a lot
faster and get the client back up and running.

However, having said that, I do not mean I do not go diving into the
logs to try and get a clue as to what the hell went wrong - hardware or
software wise. But as you also know, the error codes, log comments and
other listing data found in them are subject to many inaccuracies
leading you down the deep bunny hole to nowhere. So it's the hardware
logs that get a quick look, security and the Admin level logs and if I
can't get a clue by then, then it's time to just fix it and worry about
what happened at a later time.

Clients don't like paying for "research" time. Think of a PC as being
modular. A drive crashes, you replace it. A monitor goes up in smoke -
again you replace it. Same for the software - reimage or reload. Yes,
I would like to know what happened and learn from it if possible but the
client only wants to know "Is it fixed - yet?"

We have two distinct approaches to getting a system back up and running.
Yours is a great teaching tool method, mine is more "Do this and never
mind why". Your approach is definitely more suited to teaching than
mine - no doubt about it. That comes from 20 years in the AF and
working with FAA keeping systems up and running at all costs when
aircraft are depending on those ground systems. Fix it - worry about
why later....

So keep digging - we're all reading.....


What I'm doing is looking for "less destructive" evidence the
file set is OK.

Paul

"Paul" wrote in message news

Bob_S wrote:
"Paul" wrote in message news

Bob_S wrote:
"Bob_S" wrote in message news
"Peter Jason" wrote in message
...

When I open "Event Viewer" I get these, in sequence.
https://postimg.org/image/snsk7cnxh/

Where can I get this "Snap In"?


Below is bat file you can use to clean out the logs as someone else
suggested. Copy it into Notepad and save it as Clean.bat to your
desktop - be sure it doesn't have the .txt extension. Then
right-click and select "Run as Administrator". It will open a command
window and you will see all the logs being cleaned out.

Maybe it will help - maybe not.

And now for the secret sauce I forgot to paste in.....

@echo off
FOR /F "tokens=1,2*" %%V IN ('bcdedit') DO SET adminTest=%%V
IF (%adminTest%)==(Access) goto noAdmin
for /F "tokens=*" %%G in ('wevtutil.exe el') DO (call :do_clear "%%G")
echo.
rem echo goto theEnd

:do_clear
echo Clearing %1
wevtutil.exe cl %1
goto :eof
:noAdmin
exit

Bob S.

It looks like the log files are here, and
one for each logging area. At first I was concerned
this was stored in a .edb (which would mean more
complications for cleanup).

C:\Windows\System32\winevt\Logs

The files, if you right click, appear to be bound
to a "snapin launcher", which just looks like some
sort of App (Metro) invocation.

Event Viewer Snapin Launcher

C:\WINDOWS\system32\eventvwr.exe.FriendlyAppName === An App ???

*******

The file format is here. And visually, isn't
all that pleasing, as the double-byte characters
aren't "switched on" by any sort of global declaration.
(No BOM at the beginning of the file to make it
readable easily by humans.) You'd swear the file
was binary when looking at it.

https://github.com/libyal/libevtx/bl...EVTX).asciidoc

This looks like this program may read the "raw"
event files (EVTX), as the comments on this web page
mention making a shadow of C: before attempting to
access the files. Since the files are in constant usage,
you'd expect some sort of complications to getting at
them. My guess is, this gives another view of the
contents of the files. Since it's making a shadow,
or claims to be, the list of events in the window
should not update in real time. You'd need to stop
the program and start the program again, to get
the latest view of events.

https://www.nirsoft.net/utils/full_event_log_view.html
Paul

Paul,

For almost all of the logs, they are overwritten (circular logs) so they
will be cleared with the above script which is easily tested and you can
then open the Event Viewer and see the logs have been cleared except for
the debug and analytic logs which can be cleared manually. If you run
the script, one of the the very first entries tells you the debug log
can't be cleared. If you open a PowerShell command (admin rights) and
paste this in:

wevtutil el | Foreach-Object {wevtutil cl "$_"}

you will see the message about the channel being an "Enabled direct
channel" which first must be disabled - (e.g. made to be a circular log
or manually cleared).

The script does not force any log to have a shadow copy made since most
are circular logs and are always being overwritten.

I'm not a deep diver when it comes to researching the intricacies of
Windows these days. I need enough info to get things fixed, back up and
running. The detail you provide in your replies shows that you are
certainly detail oriented - most likely because your past or present work
require that depth of research.

I'm not interested in knowing what a virus / malware did to the system.
It's broke - fix it the fastest way possible. With the complexity of
software and operating systems today (as you just demonstrated using a
simple log cleaning as an example), I can do a reimage of a system a lot
faster and get the client back up and running.

However, having said that, I do not mean I do not go diving into the logs
to try and get a clue as to what the hell went wrong - hardware or
software wise. But as you also know, the error codes, log comments and
other listing data found in them are subject to many inaccuracies leading
you down the deep bunny hole to nowhere. So it's the hardware logs that
get a quick look, security and the Admin level logs and if I can't get a
clue by then, then it's time to just fix it and worry about what happened
at a later time.

Clients don't like paying for "research" time. Think of a PC as being
modular. A drive crashes, you replace it. A monitor goes up in smoke -
again you replace it. Same for the software - reimage or reload. Yes, I
would like to know what happened and learn from it if possible but the
client only wants to know "Is it fixed - yet?"

We have two distinct approaches to getting a system back up and running.
Yours is a great teaching tool method, mine is more "Do this and never
mind why". Your approach is definitely more suited to teaching than
mine - no doubt about it. That comes from 20 years in the AF and
working with FAA keeping systems up and running at all costs when
aircraft are depending on those ground systems. Fix it - worry about why
later....

So keep digging - we're all reading.....


What I'm doing is looking for "less destructive" evidence the
file set is OK.

Paul

You can to some extent by simply viewing the Reliability history. Enter
reliability into the search bar and look at the days (or weeks) of the file
history available in the graph. I don't know the exact file sets used in
the index scheme but I've found it to be one of the easiest "fast look"
methods to see what in the hell happened. It's not often a log gets
corrupted but I have seen an error message presented in the reliability
history comments that a log could not be read or accessed and it listed an
error code that went no where. That would probably be a good clue as to the
integrity of a subset of the logs.

But even MS does not have a good sanity check for the logs that I know of
since they are considered temporary (throw away). Now maybe NirSoft has
some kind of log verify option in his Event Viewer but I'm unlikely to
introduce a tool like that on a clients system except under extreme
conditions and then only with client approval - and an explanation of why
it's needed. The rationale for that is because on most commercial, small
business installations, they must comply with DSS PCI requirements (credit
card systems) and introducing a software "tool" that is not known or not
have been in their system while they were audited can cause some grief.

I just went thru some "grief" a couple of months ago over having UltraVNC
installed on a workstation to access an internal Bosch catalog system that I
have in a VM that had not been added to the list of installed software. I
forgot about it, they found it, we got dinged and I had to prove it did not
touch the credit card subnets. No big deal but I couldn't charge the client
for my mistake either. So yes, UltraVNC is now listed on workstation A that
needs access to the catalog VM - as now verified and dutifully recorded by
the DSS PCI audit team. Lesson learned.

So while your question is certainly valid about the integrity of the log
dataset - from my perspective, using a tool that is not from MS and on the
system already may damn well get you your answer, it can also create real
headaches. I have a number of "handy" tools that I use in my office and on
my test bench if I have to bring a clients system in. But in those cases,
it's usually because the muffler bearings went south and I'm only using
those kinds of tools to satisfy my curiosity. But I have also used them when
I needed to prove that a software vendor had bugs in his code. Telling MS
they have a bug in their logging and error codes is not news to them and a
futile exercise unless you're an IT guru at a large enterprise company that
has a zillion MS licenses.

For the small guy, keep it real, get in, get out quickly, smile and always
remember the golden rule - "Fix the customer first - the hardware second."
--
Bob S.