简介如何查看电脑使用记录是一份面向普通电脑用户与系统管理维护者的实用doc说明文档系统讲解通过系统日志、计划任务日志、运行历史、浏览器缓存等途径追踪电脑开关机、程序运行、文档访问及上网浏览记录的具体操作方法。资源包仅含1个doc文件共30KB轻量易用可直接查阅或打印对照操作。目前已有6300人学习下载适用于需要监控设备使用情况、排查使用痕迹或进行系统维护的入门至进阶用户。文档主体分三大部分展开一是开机记录涉及SchedLgU.txt计划任务日志、事件查看器中的eventlog事件筛选以及systeminfo命令查看开机时长二是文档记录通过Prefetch预读取文件夹、Recent最近访问文件、History历史文件夹及事件查看器查找本地操作痕迹三是上网记录利用Temporary Internet Files缓存和IE历史记录还原浏览网址。掌握这些方法后可有效了解电脑使用状况辅助家长管理、企业审计或个人自查。1. 电脑使用记录都藏在哪先想清楚你要查什么一个反直觉的事实是Windows 系统里关于“你什么时候用了电脑、用了哪些软件、浏览了哪些网页”这件事系统自己一直在偷偷记只是大多数人都不知道去哪翻。很多人一上来就装各种监控软件、翻所谓“上网记录”实际上系统原生记录、浏览器历史和文件访问痕迹早就把这些覆盖了七八成。这篇笔记围绕“怎么拿到这些记录、怎么把它们变成可读的时间线、再落地成一套能定期自查或做基础审计的方法”展开。适合三种人想确认自己电脑有没有被动过的人、要做终端使用情况登记的技术人员、以及被要求交“谁用了这台电脑、干过什么”的运维同学。2. 事件查看器与登录日志五分钟建立起时间基线2.1 先认识事件 ID哪些编号才是真正的“使用痕迹”Windows 所有和登录、关机、系统行为相关的记录基本都在“事件查看器”的 Windows 日志里。每次有人开机、注销、成功输错密码、远程登录失败都会写入对应的事件。很多人打开事件查看器后面对几百条事件无从下手就是因为不认编号。核心的几个事件 ID 记住即可4624登录成功代表有人成功进入了系统身份有可能是本机用户、域用户也可能是服务账户。4625登录失败具体是输错密码还是账户不存在在事件详情里有子状态码。4634 / 4647注销事件分别对应当前用户主动注销和因关机导致的注销。6005、6006事件日志服务启动与停止基本可以对应到开机与关机瞬间。41Kernel-Power系统意外断电或崩溃如果夜里有这个事件说明机器不是正常关机。这些编号在 Windows 7 到 Windows 11 上基本一致靠它们可以把“电脑开过机、登录过几次、什么时候关的”这条时间线拉出来。这也是后面所有分析和报表脚本的骨架。2.2 用一个命令把登录记录导出成可读表格很多教程让你在事件查看器里一层一层点然后手动筛选。记录少的时候无所谓但一台用了半年的电脑安全日志里可能躺着几万条事件手工筛选根本不现实。习惯做法是直接用 PowerShell 查安全日志把结果导成 CSV再交给 Excel 或脚本去筛选。Get-WinEvent -LogName Security -MaxEvents 5000 | Where-Object { $_.Id -in 4624,4625,4634,4647 } | Select-Object TimeCreated, Id, {nUser;e{$_.Properties[5].Value}}, {nLogonType;e{$_.Properties[8].Value}}, {nSourceIP;e{$_.Properties[18].Value}} | Export-Csv -Path C:\logins.csv -NoTypeInformation -Encoding UTF8这段命令的逻辑是从安全日志取最近 5000 条事件只过滤掉登录相关的四个编号然后挑出时间、事件 ID、用户名、登录类型和来源 IP 五列导出到 C 盘根目录的 logins.csv。重点解释两个参数Properties 数组里的下标对应事件 XML 里的字段顺序第 6 个值是用户名第 9 个是登录类型第 19 个是源 IP这个顺序在 Windows 10 和 Windows 11 上相对稳定。看到导出的表后要会看 LogonType 这列这是判断“是不是真人坐在屏幕前”的关键。LogonType 为 2 是本地键盘交互登录也就是有人在显示器前面输密码为 10 是远程交互登录意味着有人通过远程桌面等手段进过系统为 3 是网络登录访问共享文件夹也会触发生成记录。如果一台明明没人用的服务器频繁出现 LogonType 为 2 的登录那大概率是有人在机房或虚拟机控制台动了它。查询过程中还要注意安全日志默认只有启动审核策略之后才记录如果策略没开这条命令跑完会提示无法查询。这个问题会在后面避坑章节单独展开。3. 浏览器与文件痕迹把“用电脑”补全成完整行为链3.1 浏览器历史的数据藏在 SQLite 文件里登录日志告诉你“谁在什么时间进了系统”但没告诉你“进了系统干了什么”。补全这条链路的头号数据源是浏览器历史。Chrome、Edge 这类基于 Chromium 的浏览器会把访问过的网页、输入过的 URL、点击时间全部存进一个 SQLite 数据库文件。文件路径在C:\Users\你的用户名\AppData\Local\Google\Chrome\User Data\Default\History C:\Users\你的用户名\AppData\Local\Microsoft\Edge\User Data\Default\HistorySQLite 文件不能直接双击打开拿 DB Browser for SQLite 这一类工具访问即可。真正有用的表是 urls 和 visits前者记录访问地址和标题后者记录访问时间。两者通过 url 表的 id 关联。不装图形工具也可以用 Python 自带 sqlite3 模块读取几行代码就可以把最近一个月的访问记录按时间排序导出来。import sqlite3, shutil, os, datetime src os.path.expandvars(r%LOCALAPPDATA%\Google\Chrome\User Data\Default\History) dst rD:\temp\history_copy # 浏览器运行时 History 被文件锁占用复制一份再查 shutil.copy2(src, dst) conn sqlite3.connect(dst) cur conn.cursor() rows cur.execute( SELECT datetime(v.visit_time/1000000 - 11644473600, unixepoch) AS visit_time, u.url, u.title FROM visits v JOIN urls u ON v.url u.id ORDER BY v.visit_time DESC LIMIT 200 ).fetchall() for r in rows: print(r)这段代码有几个细节值得留意。第一行通过 expandvars 把 %LOCALAPPDATA% 展开成实际用户目录能适配不同机器。第二行先复制文件再接库是因为浏览器进程运行时 History 数据库被占用直接连接大概率报锁错误这是很多人第一次写这段代码就翻车的地方。visit_time 字段存储的是 Windows 1601 纪元微秒数必须经过公式减去 11644473600 再转 unixepoch否则显示的时间会比实际晚几百年属于典型的“数据也对但就是离谱”。3.2 最近打开的文件与运行记录被忽略的本地痕迹除了浏览器系统至少还有两处被忽略的活动记录最近使用的文件列表和运行管理器的执行记录。前者路径如下C:\Users\你的用户名\AppData\Roaming\Microsoft\Windows\Recent Items这个目录下是一堆 .lnk 快捷方式名称就是文件名修改时间反映了最近一次打开它的时间。优点是查询极快不需要任何工具缺点是有时候系统替换快捷方式而不更新修改时间所以它适合做“定性”证据不适合做精准的分钟级时间线。运行管理器记录的位置在注册表HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU可以用 reg query 命令直接查看。这个键下保存的是用户在“WinR”运行框里敲过的命令对排查“谁在这台电脑上运行过程序”很有用但它只记最近若干条而且只记录手动运行过的命令通过双击快捷方式启动的程序不写进键里。reg query HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU /s如果想让这些“点状记录”变成完整的时间线我一般会再做一步把 Recent Items 里所有快捷方式的修改时间统一扫一遍按文件类型归档。一个文件夹几十个快捷方式靠肉眼看不出规律脚本扫出来就知道“下午两点大量打开了 Office 文档”说明那段时间大概率在办公而不是在刷网页。当登录日志、浏览器历史、最近文件三份数据拼在一起一条行为链才算完整LoginType 2 的登录事件对应“人在机器前”浏览器记录对应“在上网”Recent Items 对应“在改文档”。后面要做报表或者审计就是基于这三份数据的交叉而不是单纯看某一个。4. 主动监控从“事后翻记录”到“事前留下痕迹”4.1 本地安全审核策略三条必开的审计规则前面讲的都是被动查已有记录。但默认的 Windows 配置并不会把登录日志完整保留有不少历史记录会被系统自动覆盖而且像“谁看了某个文件”这种事默认根本不记录。想稳定地查看电脑使用记录就必须先把系统的审计策略打开。打开本地安全策略组依次进入“本地策略 → 审核策略”关注以下三项审核登录事件成功和失败都要选上这是登录记录的上游开关不打开的话前面 Get-WinEvent 什么都查不到。审核进程创建成功选项勾上。进程创建是排查“运行过什么程序、有没有启动奇怪的 exe”的关键数据来源。审核对象访问这个慎开它会针对特定文件夹的每一次访问生成事件日志增长速度很快不是必要不要全局开而是配合特定目录的审计属性单独配。配置方式不只有图形界面。在管理员权限的终端下可以直接用 auditpol 命令设置效果相同适合批量分发到多台机器auditpol /set /subcategory:登录 /failure:enable /success:enable auditpol /set /subcategory:进程创建 /success:enable auditpol /get /subcategory:登录auditpol 的前两个参数指定子类和动作/set 生效是即时的不用重启。最后一条 /get 用于校验配置有没有写进去看到 success/failure 都是 enable 就说明生效。有一点要清楚改了策略只会影响之后产生的记录历史缺口是补不回来的所以“从一开始就把策略设好”才是正路。4.2 给安全日志加一份自动备份脚本开了审计之后日志文件还是会按照大小上限循环覆盖。Windows 默认把 Windows 日志的容量上限设成 20MB 左右记录多的时候一两天就滚没了。常见的做法是写一个计划任务每天把安全日志导出留存同时清出空间给后续记录用——相当于给系统日志做了“归档”。$timestamp Get-Date -Format yyyyMMdd_HHmmss wevtutil epl Security D:\EventLogs\Security_$timestamp.evtx /q:*[System[(EventID4624 or EventID4625 or EventID4634)]]wevtutil 的 epl 参数负责导出指定日志中符合查询条件的部分/q 后面的 XPath 表达式限定只导出登录相关的三类事件这样归档文件不会因为写入全部日志而迅速膨胀。导出路径需要已经提前建好不然命令会报错。导出之后需要确认一件事归档文件是否可用。可以写一条命令在导出的文件上跑一遍查询确认事件数量和内容都正常否则将来等要用的时候才发现文件是坏的就变成空欢喜一场。计划任务这一步用“任务计划程序”配置即可触发器设为每天零点操作为启动 PowerShell 并执行上面脚本运行身份选 SYSTEM 就能免密执行。这个做法不依赖任何第三方软件Windows 原生就能完成归档符合大多数内网环境不允许安装额外代理工具的约束。5. 避坑为什么你总是查不到记录5.1 现象安全日志是空的一条登录记录都没有原因最常见的是“本地安全策略里的审核登录事件”没有开启默认状态下 Windows 不会记录登录成功事件安全日志里只有几条系统启动事件。解决先运行 auditpol /get /subcategory:登录如果显示 no auditing就执行前面章节提到的 auditpol /set 命令开启。历史缺口无法恢复只能往前覆盖。这也是为什么我建议新部署的机器第一时间就要把策略配好而不是等一个月后需要数据了再回首查看。5.2 现象登录日志的时间比实际时间差了 8 小时原因事件日志存储的是本地时间但很多备份或导出脚本里混入了 UTC 时间戳做转换导致读出来和时钟对不上。另外如果系统时间本身被改过所有记录都会跟着偏移。解决在导出 CSV 时就直接用 TimeCreated 字段的原始值不要二次做时区换算。判断时间是否可信的标准是开机事件 6005 的记录时间是否和实际开机时间一致如果这个都偏了说明系统时间曾被动过或者时间服务异常日志的时序就需要谨慎核对了。5.3 现象浏览器历史被清空了任何记录都读不到原因浏览器设置里的“清除浏览数据”功能会删掉 History 文件内容SQLite 里只留下空表。另外系统和浏览器自身在更新时也可能触发历史数据清理只是用户没注意到弹窗勾选项。解决如果你能看到 History 文件但里面 url 表为空只能说明清理已经发生。想补救要看系统的文件和注册表中是否还有残留痕迹比如浏览器缓存目录里的缩略图、DNS 缓存等。普通排查场景中这些线索只能证明“上过某个网站”不能还原具体访问时间和页面。5.4 现象登录记录里的来源 IP 全是 127.0.0.1原因事件中记录的 SourceIP 是客户端地址本机登录时写的是 127.0.0.1 而不是真实 IP这是 Windows 的正常行为不是配置出错。很多人第一次看到这个地址以为是有人做了端口转发。解决要区分登录类型。LogonType 为 2 的本地登录来源 IP 本就不需要分析只有 LogonType 为 10 的远程登录SourceIP 才值得关注。远程登录的 IP 也指向本机回环地址的时候才需要考虑是不是远程桌面走了环回代理或隧道。5.5 现象导出的 CSV 里用户名显示为 SID 而不是账户名原因事件日志里存储账号名的方式在某些事件下是字符串、某些事件下只有 SID安全标识符特别是域环境或 Windows 11 的某些事件类型里体现得很明显。直接按列导出就会得到一串 S-1-5-21 开头的数字。解决导出时不要直接从 Properties 数组里取改成用事件对象自带的属性解析。下面的代码在取用户名的同时做了 SID 到账户名的转换虽然多了一层处理但结果稳定得多Get-WinEvent -LogName Security -MaxEvents 5000 | Where-Object Id -eq 4624 | ForEach-Object { $sid $_.Properties[5].Value try { $user (New-Object System.Security.Principal.SecurityIdentifier($sid)).Translate([System.Security.Principal.NTAccount]).Value } catch { $user $sid } [PSCustomObject]{ Time $_.TimeCreated; User $user } }这里的核心是 Windows PowerShell 的 Sid 到账户名翻译机制把事件里的 SID 转换成 SecurityIdentifier 对象再调用 Translate 方法翻译为 NTAccount 格式。失败时保留原始 SID既不会因为一条解析错误中断整个导出流程又保留排查线索。域环境里如果机器处于离线状态翻译可能超时所以 try/catch 非常必要。6. 进阶技巧从“能看到记录”到“自动生成使用报告”多年的血泪经验告诉我真正有用的不是某个查询命令而是把查询固化成一套例行机制。我自己常用的落地做法是每周让计划任务跑一个 PowerShell 脚本自动把过去七天的登录事件和运行过的程序汇总成一份 HTML 报告然后发到固定邮箱。这里的关键不是邮件而是报告里必须包含三个维度的信息登录会话时间线、非工作时间内的登录提醒、关键程序执行频次。报告脚本的大致骨架是用 Get-WinEvent 拉一周安全日志筛选 4624 事件按天分组统计登录次数再读 Security 日志中的 4688 进程创建事件筛出非白名单程序名最后把结果拼成 HTML 表格保存。把异常逻辑直接用规则表达凌晨两点后的成功登录直接标红比让人对着 CSV 一行行找高效得多。这一步就完成了从“事后查看”到“主动感知”的转变。其实还有一个容易被忽略的细节锁屏策略。如果只想防同办公室的人乱动电脑WinL 习惯比任何监控工具都管用。记录固然能还原事实但恢复不了已经被泄露的数据。所以这些日志查询和审计手段更多是给已经发生的怀疑提供证据而不是安全托底。用一段为自己电脑搭了半年日志归档脚本的人的经验来说就是把工具建好不难难的是每天愿意花五分钟看一眼异常记录的习惯。希望这些经验能帮你在需要的时候少走些弯路多留些底牌。本文还有配套的精品资源点击获取