990x.top

Простой компьютерный блог для души)

gatherNetworkInfo.vbs в автозагрузке что это за программа?

Всем привет. Господа, сегодня у нас не обычная задача, я должен узнать что такое gatherNetworkInfo.vbs, ибо это часто, вернее некоторые юзеры могут заметить в автозагрузке. Что это за дичь редкая, подумал я? Сразу мысли в голову полезли, может это вирус? Угроза.. ? Но если посмотреть внимательно на сам файл gatherNetworkInfo.vbs, то понятно сразу, это скрипт, ибо расширение vbs ведь… А вот само название… Ну первое слово gather, это не знаю что, но посмотрел в переводчик и узнал что это переводится как собирать. Ну а NetworkInfo это я уже знаю что, переводится как информация о сети… Так, хм, то есть это что, получается скрипт о сборе информации о сети? Ну другое в голову ничего не приходит… Окей, я еще пороюсь в пространстве интернета, может еще какую инфу найду…

Вот что мне удалось выяснить. Этот скрипт обычно расположен в системной папке System32, что как бы намекает на то, что он системный вроде как. В некоторых программах, где вы можете посмотреть автозагрузку, то там может также указываться что файл gatherNetworkInfo.vbs не имеет цифровой подписи. Вы можете прочитать в интернете, мол что если нет цифровой подписи, то это норм, ибо скриптовый файл типа нереально подписать. Я тоже так думал, но оказывается что его подписать все таки можно! Но почему тогда gatherNetworkInfo.vbs не подписан? Не знаю, может просто это не столь важно….

Еще узнал что скрипт gatherNetworkInfo.vbs обычно запускается при помощи запланированного задания, которое можно найти в планировщике виндовском. Этот скрипт присутствует вроде как во всех виндах начиная с Windows Vista. То есть первый вывод уже можем сделать, данный скрипт как я понимаю идет системным, то есть это не вирусня, это реально системный компонент винды.

Так, задание, при помощи которого запускается gatherNetworkInfo.vbs, то оно находится в разделе \Microsoft\Windows\NetTrace\ в планировщике и называется оно GatherNetworkInfo. Там его можно отключить или даже удалить, лучше всего отключить его и проверить, если проблем не будет, то можно потом и удалить… Хотя лучше таки оставить, кушать то оно все равно не просит…

Кстати расширение vbs расшифровывается как Visual Basic Scripting Edition.

Вот еще узнал, что gatherNetworkInfo.vbs в автозагрузке обычно сидит потому что задача тупо включена и все. Но при этом в самом задании нужно посмотреть там где триггеры, там есть что-то? Там в триггерах может быть указана программа, которая требует выполнения задания. Ибо если нет программы, то задача получается есть, а кому ее выполнять, то тут нет никого и в итоге никакого действия она вообще не делает.

Еще на некоторых сайтах очень уверенно говорят что файл gatherNetworkInfo.vbs не имеет никакого отношения к винде. Откуда такая уверенность я ума не приложу, особенно учитывая то что антивирусы или антивирусные утилиты не видят ничего опасного в этом файле.

Как я понял, то задание gatherNetworkInfo.vbs можно удалить, вот один чел удалил и пишет что все норм, никаких проблем не заметил. Перед удалением я конечно же рекомендую создать точку восстановления, мало ли…

На другом сайте я нашел инфу, все подтвердилось. Да, есть такое задание как GatherNetWorkInfo, оно нужно для сбора инфы о использовании сети, также ведет статистику отправляемых пакетов, скорости соединения. И вроде таки можно отключить.

Я решил у себя тоже посмотреть, уж страшно интересно стало, есть ли у меня в планировщике задание GatherNetWorkInfo? Если что у меня Windows 10.. Итак, открыл я панель управления (кстати для этого можете зажать Win + R и потом вставить команду control panel), потом там в правом верхнем углу написал слово план, и я увидел кнопку планировщика:

Запустил, немного подождав, потом все таки показалось окно планировщика:

Так, теперь переходим в раздел, где сидит задание GatherNetWorkInfo, ну то есть вот сюда:

То есть сначала открываем раздел Windows:

И в нем уже ищем раздел NetTrace:

Выбрали раздел, смотрим вправо и вот я вижу что у меня есть задание GatherNetworkInfo, смотрите:

Ну что, делаем самое интересненькое? Я нажимаю по заданию два раза.. Открывается вот такое окошко:

Ну как видите, тут так и написано, что это Сборщик сведений сети. Окей, окей… И еще внизу вижу что стоит галочка Выполнять с наивысшими правами.. Все признаки того что это системное задание.. Блин, я забыл. Это ведь моя рабочая винда, верно? Верно! А тут вирусов нет и быть не может, поверьте, у меня все продумано, тут я даже никакие проги никогда не ставлю, необходимые поставил и все. Игр вообще нет. Вирусы короче исключены, так что вам еще одно подтверждение того, что GatherNetworkInfo это СИСТЕМНОЕ И БЕЗОПАСНОЕ ЗАДАНИЕ, удалять можно, но смысл.. ? Так, ладно, мне еще оч любопытно посмотреть что там на вкладке Триггеры.. вот я ее открыл, и смотрите, тут тупо пусто:

То есть задание есть, но оно не выполняется, ибо нет потребности. Видимо выполняется оно таки по запросу. При этом всем, если перейти на вкладку Действия, то тут будет написано что есть действие, и это выполнение скрипта gatherNetworkInfo.vbs:

Ага, блин, я попутал немного! Блин, вот дела…!! В общем вкладка Триггеры, это там должно быть РАСПИСАНИЕ ВЫПОЛНЕНИЯ, но его нет, потому что это задание выполняется по запросу, а не при запуске винды! Это нужно понимать ребята. Другие вкладки я вам не показываю, там нет ничего особенного, ну то есть ничего интересного

А вот некоторые юзеры, у которых стоит AnVir Task Manager, то они там и увидели запись с gatherNetworkInfo.vbs:

Да, все верно, там оно может показывать что уровень риска 46%, но я все проверил, у меня тоже есть это задание, так что если у меня есть, то это реально стопудово безопасное задание и gatherNetworkInfo.vbs ну никак не вирус. Правда вы можете мне не верить, но смысл мне врать то….

Также я нашел в сети картинку, это открыты свойства файла gatherNetworkInfo.vbs, смотрите:

Видите тут дату? 2009-тый год, такой год и у остальных системных файлов, не у всех, но у многих… Я сам бывало смотрел свойства системных файлов, я имею ввиду именно в Windows 7, и там тоже был именно 2009-тый год.

Вот еще одна картинка, это снова AnVir Task Manager, тут он прям вообще говорит что файл gatherNetworkInfo.vbs то рискованный страшно капец:

Вы тут можете меня спросить, так что, AnVir Task Manager плохая прога? Нет! Просто AnVir Task Manager думает так: это файл vbs, то есть скрипт, что внутри непонятно, стоит в автозагрузке, это немного подозрительно. И все правильно, ибо такие мутки часто мутят именно вирусяки! Но тут все чисто, я думаю что вы уже это понимаете.

Ребята, накидаем выводов?

1. gatherNetworkInfo.vbs это никак не вирус, это задание GatherNetworkInfo в планировщике, их там вообще этих заданий целая туча, много нам незнакомые, так что, теперь считать что это все вирусы?
2. Задание GatherNetworkInfo есть в каждой винде, начиная с Windows Vista, в XP как я понимаю его нет.
3. У меня на рабочем компе задание GatherNetworkInfo присутствует, ну а у меня вирусы исключены стопудово, ибо стоит фаервол и обновления регулярные и левак не качается воообще!
4. Если вам все таки кажется что что-то не так, то советую проверить комп Dr.Web CureIt и AdwCleaner, это лучшие антивирусные утилиты, но ищут принципиально разные угрозы, поэтому проверять нужно двумя.

На этом все господа, надеюсь что я помог вам, что вы поняли что GatherNetworkInfo это штатное виндовское задание, бояться нечего. Однако антивирусными утилитами я бы комп все таки проверил на вашем месте… иди знай.. вдруг вирус маскируется… Хотя это маловероятно, но все же. Берегите себя дорогие ребята!

dotnet-trace performance analysis utility

This article applies to: вњ”пёЏ .NET Core 3.0 SDK and later versions

Install

There are two ways to download and install dotnet-trace :

dotnet global tool:

To install the latest release version of the dotnet-trace NuGet package, use the dotnet tool install command:

Direct download:

Download the tool executable that matches your platform:

OS	Platform
Windows	x86 | x64 | arm | arm-x64
macOS	x64
Linux	x64 | arm | arm64 | musl-x64 | musl-arm64

To use dotnet-trace on an x86 app, you need a corresponding x86 version of the tool.

Synopsis

Description

The dotnet-trace tool:

• Is a cross-platform .NET Core tool.
• Enables the collection of .NET Core traces of a running process without a native profiler.
• Is built on EventPipe of the .NET Core runtime.
• Delivers the same experience on Windows, Linux, or macOS.

Options

-h|—help

Shows command-line help.

—version

Displays the version of the dotnet-trace utility.

Commands

dotnet-trace collect

Collects a diagnostic trace from a running process.

Synopsis

Options

—buffersize

Sets the size of the in-memory circular buffer, in megabytes. Default 256 MB.

If the target process writes events too frequently, it can overflow this buffer and some events might be dropped. If too many events are getting dropped, increase the buffer size to see if the number of dropped events reduces. If the number of dropped events does not decrease with a larger buffer size, it may be due to a slow reader preventing the target process’ buffers from being flushed.

—clreventlevel

Verbosity of CLR events to be emitted.

—clrevents

A list of CLR runtime provider keywords to enable separated by + signs. This is a simple mapping that lets you specify event keywords via string aliases rather than their hex values. For example, dotnet-trace collect —providers Microsoft-Windows-DotNETRuntime:3:4 requests the same set of events as dotnet-trace collect —clrevents gc+gchandle —clreventlevel informational . The table below shows the list of available keywords:

Keyword String Alias	Keyword Hex Value
gc	0x1
gchandle	0x2
fusion	0x4
loader	0x8
jit	0x10
ngen	0x20
startenumeration	0x40
endenumeration	0x80
security	0x400
appdomainresourcemanagement	0x800
jittracing	0x1000
interop	0x2000
contention	0x4000
exception	0x8000
threading	0x10000
jittedmethodiltonativemap	0x20000
overrideandsuppressngenevents	0x40000
type	0x80000
gcheapdump	0x100000
gcsampledobjectallocationhigh	0x200000
gcheapsurvivalandmovement	0x400000
gcheapcollect	0x800000
gcheapandtypenames	0x1000000
gcsampledobjectallocationlow	0x2000000
perftrack	0x20000000
stack	0x40000000
threadtransfer	0x80000000
debugger	0x100000000
monitoring	0x200000000
codesymbols	0x400000000
eventsource	0x800000000
compilation	0x1000000000
compilationdiagnostic	0x2000000000
methoddiagnostic	0x4000000000
typediagnostic	0x8000000000

You can read about the CLR provider more in detail on the .NET runtime provider reference documentation.

Sets the output format for the trace file conversion. The default is NetTrace .

-n, —name

The name of the process to collect the trace from.

The name of the diagnostic port to create. See Use diagnostic port to collect a trace from app startup to learn how to use this option to collect a trace from app startup.

The output path for the collected trace data. If not specified, it defaults to trace.nettrace .

The process ID to collect the trace from.

A named pre-defined set of provider configurations that allows common tracing scenarios to be specified succinctly. The following profiles are available:

Profile	Description
cpu-sampling	Useful for tracking CPU usage and general .NET runtime information. This is the default option if no profile or providers are specified.
gc-verbose	Tracks GC collections and samples object allocations.
gc-collect	Tracks GC collections only at very low overhead.

A comma-separated list of EventPipe providers to be enabled. These providers supplement any providers implied by —profile

. If there’s any inconsistency for a particular provider, this configuration takes precedence over the implicit configuration from the profile.

This list of providers is in the form:

• Provider[,Provider]
• Provider is in the form: KnownProviderName[:Flags[:Level][:KeyValueArgs]] .
• KeyValueArgs is in the form: Microsoft windows net trace[;key2=value2] .

To learn more about some of the well-known providers in .NET, refer to Well-known Event Providers.

— (for target applications running .NET 5.0 only)

After the collection configuration parameters, the user can append — followed by a command to start a .NET application with at least a 5.0 runtime. This may be helpful when diagnosing issues that happen early in the process, such as startup performance issue or assembly loader and binder errors.

Using this option monitors the first .NET 5.0 process that communicates back to the tool, which means if your command launches multiple .NET applications, it will only collect the first app. Therefore, it is recommended you use this option on self-contained applications, or using the dotnet exec option.

Stopping the trace may take a long time (up to minutes) for large applications. The runtime needs to send over the type cache for all managed code that was captured in the trace.

On Linux and macOS, this command expects the target application and dotnet-trace to share the same TMPDIR environment variable. Otherwise, the command will time out.

To collect a trace using dotnet-trace , it needs to be run as the same user as the user running target process or as root. Otherwise, the tool will fail to establish a connection with the target process.

If you see an error message similar to the following one: [ERROR] System.ComponentModel.Win32Exception (299): A 32 bit processes cannot access modules of a 64 bit process. , you are trying to use dotnet-trace that has mismatched bitness against the target process. Make sure to download the correct bitness of the tool in the install link.

dotnet-trace convert

Converts nettrace traces to alternate formats for use with alternate trace analysis tools.

Synopsis

Arguments

Input trace file to be converted. Defaults to trace.nettrace.

Options

—format

Sets the output format for the trace file conversion.

-o|—output

Output filename. Extension of target format will be added.

Converting nettrace files to chromium or speedscope files is irreversible. speedscope and chromium files don’t have all the information necessary to reconstruct nettrace files. However, the convert command preserves the original nettrace file, so don’t delete this file if you plan to open it in the future.

dotnet-trace ps

Lists the dotnet processes that traces can be collected from.

Synopsis

dotnet-trace list-profiles

Lists pre-built tracing profiles with a description of what providers and filters are in each profile.

Synopsis

Collect a trace with dotnet-trace

To collect traces using dotnet-trace :

Get the process identifier (PID) of the .NET Core application to collect traces from.

• On Windows, you can use Task Manager or the tasklist command, for example.
• On Linux, for example, the ps command.
• dotnet-trace ps

Run the following command:

The preceding command generates output similar to the following:

Stop collection by pressing the key. dotnet-trace will finish logging events to the trace.nettrace file.

Launch a child application and collect a trace from its startup using dotnet-trace

This works for apps running .NET 5.0 or later only.

Sometimes it may be useful to collect a trace of a process from its startup. For apps running .NET 5.0 or later, it is possible to do this by using dotnet-trace.

This will launch hello.exe with arg1 and arg2 as its command-line arguments and collect a trace from its runtime startup:

The preceding command generates output similar to the following:

You can stop collecting the trace by pressing or key. Doing this will also exit hello.exe .

Launching hello.exe via dotnet-trace will make its input/output to be redirected and you won’t be able to interact with its stdin/stdout. Exiting the tool via CTRL+C or SIGTERM will safely end both the tool and the child process. If the child process exits before the tool, the tool will exit as well and the trace should be safely viewable.

Use diagnostic port to collect a trace from app startup

This works for apps running .NET 5.0 or later only.

Diagnostic port is a new runtime feature that was added in .NET 5 that allows you to start tracing from app startup. To do this using dotnet-trace , you can either use dotnet-trace collect — as described in the examples above, or use the —diagnostic-port option.

Using dotnet-trace — to launch the application as a child process is the simplest way to quickly trace it from its startup.

However, when you want to gain a finer control over the lifetime of the app being traced (for example, monitor the app for the first 10 minutes only and continue executing) or if you need to interact with the app using the CLI, using —diagnostic-port option allows you to control both the target app being monitored and dotnet-trace .

The command below makes dotnet-trace create a diagnostics socket named myport.sock and wait for a connection.

In a separate console, launch the target application with the environment variable DOTNET_DiagnosticPorts set to the value in the dotnet-trace output.

This should then enable dotnet-trace to start tracing my-dotnet-app :

Launching your app with dotnet run can be problematic because the dotnet CLI may spawn many child processes that are not your app and they can connect to dotnet-trace before your app, leaving your app to be suspended at runtime. It is recommended you directly use a self-contained version of the app or use dotnet exec to launch the application.

View the trace captured from dotnet-trace

On Windows, .nettrace files can be viewed on PerfView for analysis: For traces collected on other platforms, the trace file can be moved to a Windows machine to be viewed on PerfView.

On Linux, the trace can be viewed by changing the output format of dotnet-trace to speedscope . The output file format can be changed using the -f|—format option — -f speedscope will make dotnet-trace produce a speedscope file. You can choose between nettrace (the default option) and speedscope . Speedscope files can be opened at https://www.speedscope.app.

The .NET Core runtime generates traces in the nettrace format. The traces are converted to speedscope (if specified) after the trace is completed. Since some conversions may result in loss of data, the original nettrace file is preserved next to the converted file.

Use dotnet-trace to collect counter values over time

• Use EventCounter for basic health monitoring in performance-sensitive environments. For example, in production.
• Collect traces so they don’t need to be viewed in real time.

For example, to collect runtime performance counter values, use the following command:

The preceding command tells the runtime counters to report once every second for lightweight health monitoring. Replacing EventCounterIntervalSec=1 with a higher value (for example, 60) allows collection of a smaller trace with less granularity in the counter data.

The following command reduces overhead and trace size more than the preceding one:

The preceding command disables runtime events and the managed stack profiler.

Use .rsp file to avoid typing long commands

You can launch dotnet-trace with an .rsp file that contains the arguments to pass. This can be useful when enabling providers that expect lengthy arguments or when using a shell environment that strips characters.

For example, the following provider can be cumbersome to type out each time you want to trace:

In addition, the previous example contains » as part of the argument. Because quotes are not handled equally by each shell, you may experience various issues when using different shells. For example, the command to enter in zsh is different to the command in cmd .

Читайте также:  Mac os не работают карты