What is this Process and Why is it Running【三】

audiodg.exe

Windows音频设备图形隔离进程,是一个正常的系统进程,英文名称为audiodg.exe,windows7系统不会以英文名显示。

Windows音频设备图形隔离程序是一种系统保护进程,出于系统安全需要,用于防止未授权软件或硬件捕获高清晰度视频格式文件的内容,还可以大幅度的提升耳机音质。

对于此正常进程,一般情况下不会占用太多CPU,如果占用过高的情形一旦出现,按照这几点原因进行排查:

  1. 声卡驱动的问题,进行声卡驱动的更新【贴出更新教程】https://jingyan.baidu.com/article/d169e18603a087436611d8d7.html
  2. 检查音量设置,是否音量设置过高,音量越高越容易出问题【提醒一点,音量最好保持在60%以下】

(对于其他任务是否启用过多,自我感觉没必要,因为占用CPU详细比例已经显示在任务管理器中了)

  1. 最重要也是我最不想面对的一点,如果确定不是上边的原因,都确定好了,那么还是接受电脑有可能中毒了
顺便提供如何处理这个问题
  1. 针对Skype采取措施,卸载再重装
  2. 更新声卡驱动(上面提到了)
  3. 关掉所有声音
  4. 运行音频疑难解答
  5. 扫描病毒

http://www.ghost580.com/win10/2018-01-01/23200.html【详细解决方案】
在这里插入图片描述
任务管理器中此进程以这种形式存在,发现它是件好事,但发现它的原因就…,心有余悸,开始这个故事:

10月14日,像往常一样,我在本机中插入U盘,打开U盘,并没有看到我的那堆文件,而是有一个小小的磁盘图标开头,名为U盘快捷方式的文件,我意识到有问题了,但还是手残~双击【以后一旦有意识一定不点】,接着就看到Windows Defender报威胁了

在这里插入图片描述

本来以为确定了是GandCrab病毒了,这可是2018年的新病毒啊,对于此病毒如果请企业杀毒,开价将和赎金不相上下。

不太屈服命运的灵魂促使我进行了连续实验,果然,最新的判断为蠕虫病毒

想要进行准确判断必须铤而走险进去看了,但肯定不会关掉Windows Defender强行进去的

首先我取下U盘,对电脑进行了一次全方位扫描,任务管理器中基于前两篇

What is this Process and Why is it Running【一】

What is this Process and Why is it Running【二】

进行了一一排查,确认没有异常进程后,接着进入日志,查看了那个时间段的日志

一切的一切确认好了

下一步,送进虚拟机

与主机断开连接【在虚拟机选项中】,我在Ubuntu中进行的操作

鉴于之前未安装过exfat-utils首先sudo apt-get install exfat-fuse exfat-utils安装ExFAT支持

不然会出现这种结果

在这里插入图片描述
打开U盘,首先看到的是

  1. 我的文件被放到了一个文件夹中
  2. 多了一个文件夹叫做system volume information
  3. 多了一个文件叫做autorun.exe

点击存放我文件的文件夹,进去后一直看到最深处,依次发现了wpssetting thumbs _WAJAJIEKZP.nil IndexerVolumeGuid 等文件以及它们的重复出现【其中IndexerVolumeGuid便是我上面提到的中病毒的可能原因,这是一个控制本机音量的自动执行的文件】

一波删,shift + delete 完全删除,我将U盘上所有非正常文件全部删除,将文件单独拖出来(以至于杀完毒之后U盘需要扫描恢复)对于除此之外的几个数据文件和配置文件我选择了记录

一心想着杀毒,导致很多数据我没有全部保存下来,遗憾!!!

幸运的是碰到的病毒比较好搞,遗憾没有顺着初心判断出来具体病毒的原理,至少U盘恢复了

。。。

故事讲完了,描述中有不当的地方还请提出来

大家如果也曾碰到过同样的或者不小心碰到的可以指点指点,交流交流 QQ:1223950227

请告诉我具体的实验步骤: Lab: system calls In the last lab you used system calls to write a few utilities. In this lab you will add some new system calls to xv6, which will help you understand how they work and will expose you to some of the internals of the xv6 kernel. You will add more system calls in later labs. Before you start coding, read Chapter 2 of the xv6 book, and Sections 4.3 and 4.4 of Chapter 4, and related source files: • The user-space "stubs" that route system calls into the kernel are in user/usys.S, which is generated by user/usys.pl when you run make. Declarations are in user/user.h • The kernel-space code that routes a system call to the kernel function that implements it is in kernel/syscall.c and kernel/syscall.h. • Process-related code is kernel/proc.h and kernel/proc.c. To start the lab, switch to the syscall branch: $ git fetch $ git checkout syscall $ make clean If you run make grade you will see that the grading script cannot exec trace and sysinfotest. Your job is to add the necessary system calls and stubs to make them work. Using gdb (easy) In many cases, print statements will be sufficient to debug your kernel, but sometimes being able to single step through some assembly code or inspecting the variables on the stack is helpful. To learn more about how to run GDB and the common issues that can arise when using GDB, check out this page. To help you become familiar with gdb, run and then fire up gdb in another window (see the gdb bullet on the guidance page). Once you have two windows open, type in the gdb window: make qemu-gdb (gdb) b syscall Breakpoint 1 at 0x80002142: file kernel/syscall.c, line 243. (gdb) c Continuing. [Switching to Thread 1.2] Thread 2 hit Breakpoint 1, syscall () at kernel/syscall.c:243 243 { (gdb) layout src (gdb) backtrace The layout command splits the window in two, showing where gdb is in the source code. The backtrace prints out the stack backtrace. See Using the GNU Debugger for helpful GDB commands. Answer the following questions in answers-syscall.txt. Looking at the backtrace output, which function called syscall? Type a few times to step past struct proc *p = myproc(); Once past this statement, type , which prints the current process's proc struct (see kernel/proc.h>) in hex. np /x *p What is the value of p->trapframe->a7 and what does that value represent? (Hint: look user/initcode.S, the first user program xv6 starts.) The processor is running in kernel mode, and we can print privileged registers such as sstatus (see RISC-V privileged instructions for a description): (gdb) p /x $sstatus What was the previous mode that the CPU was in? In the subsequent part of this lab (or in following labs), it may happen that you make a programming error that causes the xv6 kernel to panic. For example, replace the statement num = p->trapframe->a7; with num = * (int *) 0; at the beginning of syscall, run , and you will see something similar to: make qemu xv6 kernel is booting hart 2 starting hart 1 starting scause 0x000000000000000d sepc=0x000000008000215a stval=0x0000000000000000 panic: kerneltrap Quit out of qemu. To track down the source of a kernel page-fault panic, search for the sepc value printed for the panic you just saw in the file kernel/kernel.asm, which contains the assembly for the compiled kernel. Write down the assembly instruction the kernel is panicing at. Which register corresponds to the variable num? To inspect the state of the processor and the kernel at the faulting instruction, fire up gdb, and set a breakpoint at the faulting epc, like this: (gdb) b *0x000000008000215a Breakpoint 1 at 0x8000215a: file kernel/syscall.c, line 247. (gdb) layout asm (gdb) c Continuing. [Switching to Thread 1.3] Thread 3 hit Breakpoint 1, syscall () at kernel/syscall.c:247 Confirm that the faulting assembly instruction is the same as the one you found above. Why does the kernel crash? Hint: look at figure 3-3 in the text; is address 0 mapped in the kernel address space? Is that confirmed by the value in scause above? (See description of scause in RISC-V privileged instructions) Note that scause was printed by the kernel panic above, but often you need to look at additional info to track down the problem that caused the panic. For example, to find out which user process was running when the kernel paniced, you can print out the process's name: (gdb) p p->name What is the name of the binary that was running when the kernel paniced? What is its process id (pid)? This concludes a brief introduction to tracking down bugs with gdb; it is worth your time to revisit Using the GNU Debugger when tracking down kernel bugs. The guidance page also has some other other useful debugging tips.
最新发布
11-16
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值