FrankHB / pl-docs

Programming Language Documentations
534 stars 44 forks source link

文本处理 #6

Open FrankHB opened 5 years ago

FrankHB commented 5 years ago

先加一个列表。部分内容待合并。

iAsiby commented 5 years ago

催更【

FrankHB commented 5 years ago

坑太大,@iAsiby 先提重点吧。

FrankHB commented 5 years ago

@ice1000 链接到你的地方借用点编辑器资源,结果connection reset by peer,撞鬼了吗……(好像没被墙 顺带加点反面教材

ice1000 commented 5 years ago

什么编辑器资源

FrankHB commented 5 years ago

什么编辑器资源

讨论代码编辑器的文本存储的实现的一些数据结构,暂时先链接到上面了。

另外你的站链接被重置上不了看来不是我的个案……(吱群有人访问显示 ERR_CONNECTION_REFUSED 。)

ice1000 commented 5 years ago

另外你的站链接被重置上不了看来不是我的个案……(吱群有人访问显示 ERR_CONNECTION_REFUSED 。)

最近刚换https,看看是不是http了?

ice1000 commented 5 years ago

讨论代码编辑器的文本存储的实现的一些数据结构,暂时先链接到上面了。

嗷。我那几篇基本覆盖了我见过的所有的。

ice1000 commented 5 years ago

我博客是GitHub的,国内可能不太稳定。有考虑过搞个国内的host

FrankHB commented 5 years ago

另外你的站链接被重置上不了看来不是我的个案……(吱群有人访问显示 ERR_CONNECTION_REFUSED 。)

最近刚换https,看看是不是http了?

所有访问全是https的。 不过GitHub有这么不稳定么……别的就是github.io的都没感觉啊。域名问题?

ice1000 commented 5 years ago

有这个可能。 还是换个coding.net的Pages服务比较靠谱……

FrankHB commented 5 years ago

暂时决定搁置这里的任务,排到这篇修订之后。

FrankHB commented 5 years ago

emmm,yinwang.org也会被reset,难道出口集体抽风么……

FrankHB commented 5 years ago

上面坑先埋一半,接下来继续对付这里的问题吧……

FrankHB commented 5 years ago

遇到一系列 M$ 智熄问题,所以多坑几天:

FrankHB commented 5 years ago

今天终于又推送了,还以为是 1903 ,不过更新完一看是 1809(17763.379) ,看起来还算正常……

FrankHB commented 5 years ago

……然后就蓝屏了,代码 MEMORY_MANAGEMENT 。。

FrankHB commented 5 years ago

又回滚了……

备份了邮件居然还有 GMail 的邮件 ost 文件是坏的……强行保留出错的文件,进入后闪退。

语言包没法降级,还是先得重装商店应用。

其它 Office 组件也无法启动,也还是得手动重装。

Powershell 重装商店应用:

Get-AppXPackage *WindowsStore* -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

想了下干脆全部重装:

Get-AppXPackage * -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

然后似乎 Word 正常了,其它的还是英文。删除损坏的 ost 总算能进 Outlook 了,就是又得重新下载和设置搜索文件夹……

iAsiby commented 5 years ago

弃坑了吗?【

FrankHB commented 5 years ago

坑大,优先级低。

或者 @iAsiby 你觉得哪些比较急先拆一部分出来。

iAsiby commented 5 years ago

可以先把基本概念之类的讲一讲。 @FrankHB

ice1000 commented 5 years ago

关于代码编辑器,可以先看我的那个系列博客

FrankHB commented 5 years ago

Windows 易作死升级到 1903 ,首先下载一坨进度快走完,提示硬件没准备好。关掉还要清理下载。

第二次拔掉扩展 TF 卡,重新升级成功(还要下载……),出来似乎不会有开个 gcc 都随便 segfault 的问题了,可喜可贺……(?)

然而,打开 Outlook :“无法在 AppData 文件夹下存储 Outlook 数据文件。请选择其他文件夹。”这又是什么鬼?┴─┴︵╰(‵□′╰)

FrankHB commented 5 years ago

好吧,直接把 %LocalAppData%\Microsoft\Outlook_AppX 这个目录链接删除以后似乎正常了。

FrankHB commented 5 years ago

2019-06-26

又随机 segfault ,WSL 下编译失败还马上蓝屏 MEMORY_MANAGEMENT ,事件来源 BugCheck

计算机已经从检测错误后重新启动。检测错误: 0x0000001a (0x0000000000061941, 0x00007fb6129d0e50, 0x000000000000000d, 0xffffc205085c7a00)。已将转储的数据保存在: C:\WINDOWS\MEMORY.DMP。报告 ID: 294abd9c-437d-4e3f-9044-d38003508b43。

查询原因

0x61941

The paging hierarchy is corrupt. Parameter 2 is a pointer to the virtual address which caused the fault.

然而并没发现有 dmp ……设置的是自动内存转储,只发现了 minidump 。WinDbg (话说商店那个 WinDbg Preview 页面显示一半,Get 都点不动,什么鬼)打开一看 ntoskrnl.exe 在 pagefault 下崩了……

因为这回不像 1809 100% 出现,是最近装了更新以后才出现的,而且重启后似乎暂时正常了,先拉个待排查清单:

但是考虑 1903 蓝屏报告根本不限 18362.175 这个版本(例如这个),而且内存可能在之前就烂了,所以实际上也不好说。看来还是要再评估几天,不过如果 WINDOWS.OLD 过期就玩脱了……

2019-06-27

蓝屏前又是一样的错误,开 verifier.exe 也没筛查出来,死马当活马医卸载 KB4503293 ,结果卸载失败再卸载蓝屏重新启动继续卸载再重启就无限重启修复 loop ┴─┴︵╰(‵□′╰),修复系统高级选项卸载更新,提示因为有一个更新正在进行中无法卸载质量更新,只能卸载功能更新……那好,又弃疗回 1803 了。这回 Outlook 倒是没打不开也没掉数据,但是 Office 365 又变成英文版的了,懒得管了,字小点就小点吧……

回 1803 后继续更新,暂时没发现问题。已安装更新列表:

2019-07-04

1803 公告停止支持,手贱点升级了……又到 18362.207 ,等挂。(实在不行滚上 Insider 作死试试……)

初始更新:

固件之前已经升级了,反正 1803 下正常。没有驱动更新。

第一次启动几个小时后就 FAULTY_HARDWARE_CORRUPTED_PAGE 了……还没装其它更新。

2019-10-21

Surface Book 2 固件更新后隔天自动更新 1903 。问题照旧(在 Win32 下构建 YSLib 解析预编译头报错,删除后没发现问题,但在 WSL 下删除 .gch 后编译器仍然 segfault 无法构建,多试几次就蓝屏还不给错误代码)。

唯一的改进是回滚旧系统后 Outlook 不会变成英文版本,邮件的目录也不会自动丢失了,但 GMail 同步失败,需要手动解决。

15:35:47 同步版本 16.0.12026.20114
15:35:47 正在同步处理邮箱“frankhb1989@gmail.com”
15:35:47 正在同步处理层次结构
15:37:33 文件夹 '收件箱' 中有错误
15:37:33         [800CCC0E-0-0-733]
15:37:33 因错误而异常终止
15:37:33         [800CCC0E-0-0-733]

邮箱设置测试邮件倒都是通的,似乎是临时性网络问题。

2019-12-04

一台非常用机器一个月前自动更新了 1903 ,没法回退了,所以再次试验。能成功构建 YSLib ,没发现内存错误,没有蓝屏。尚未部署 WSL ,待测试。

看来又遇到 Heisenbug 了么。还是说最近 Windows 更新修好了一些 bug ?或者因为这台机器用的 E3-1230v2 ?

2019-12-06

有问题的机器(现在都回退到 Windows 10 1803 )似乎都开了内核隔离(在“安全中心”的“设备安全性”中能看到),但其中的“内存完整性”(在 1803 下 )都是关的。因为一台机器坏了暂时没完全确认。

没有问题的机器显示“不支持标准硬件安全性”。

2020-05-23

Windows 易升只给更新 1909 没 2004 。更新成功 1909 试了下马上发现还是老样子,不等蓝屏就回退了。结果到 1803 后一个不注意又给我偷偷更新 1903 ,妈的智障……直接进 %WINDIR%\SoftwareDistribution 干死。

ice1000 commented 5 years ago

┴─┴︵╰(‵□′╰)

lhmouse commented 4 years ago

┴─┴︵╰(‵□′╰)

FrankHB commented 4 years ago

2020-10-22

昨天晚上 Windows 易升更新 2009 ,之后还是有 GCH 错误。

之前开 msinfo32 看到有个自动加载的可疑驱动 %WINDIR%\System32\drivers\passguard_x64.dll(影响的机器似乎都有装,另外就是 bluestack 的但看起来比较人畜无害)。看文件创建日期( 2018-06 )是人行征信验证控件时装的,先卸载了试试——也不干掉驱动——跟百度搜出来的说得一样。

因为之前停止服务试过会键盘失灵,开好屏幕键盘,sc stop passguard 然后 sc delete passguard,重启。欢迎屏幕 Windows Hello 没识别成功还明确提示要 PIN ,但没显示光标点文本框也没反应,再重启一遍照旧,不过总算点开辅助功能开屏幕键盘登录了。之后删掉对应文件,删除 GCH 重新生成 YSLib ,8 小时后仍然一切正常。

淦。

顺便这几个月 GitHub issue 的 comment 编辑也一直抽风,Basilisk 点了没反应(今天试了下是点了一直转圈圈),1803 的 Edge 也一样,Linux 的原版 Basilisk 除非卡了才能点得动,Firefox 看来因为 WSL 的问题地址栏输入任何东西都各种 Channel error 根本开不了页面(今天试了也一样)……换 20H2 的 Edge 才行,看起来偷懒倒就会适配欠扁的炒肉末了。叒鸡。原来 Basilisk 连搜索 issue 都不灵光,不过今天试了似乎修好了。

2020-10-23

对文件缓存被污染的情况,用 Empty Standby List 续命。不过因为是内核问题,也就只是能续命,不妨碍之后继续坏了或者蓝屏。另外因为 MinGW32 GCC ICE 会直接丢下半拉子 .o 文件不管,续命成功也得清理,就比较尴尬……

WSL issue 5769 有提到虚拟机平台和 vcxsrv 不明原因冲突,果然一开 vcxsrv 以后编译 YSLib 死得很快,没几分钟就蓝屏了。

但是虚拟机平台虽然是 1809 有的,但默认看来并没开。而且按那个 issue 里面说的似乎 2004 前还没问题。

反正先这样放置,至少不会一下就死了。

(因为之前空间不够看没马上挂掉作死删了旧版本所以没法回滚了……)

2020-10-24

这里提到 Windows 10 的一个性能问题可以用 Empty Standby List 解决,并建议计划任务安排上。

先用 RAMMap 确定了 Empty Priority 0 Standby List 至少对重复编译 YSLib 有效,正准备改计划任务,结果……突然就蓝屏了……

(╯-_-)╯╧╧

2020-10-26

灵机一动关闭了 SysMain 服务(以前叫 Superfetch ),居然就正常了 24 小时以上……

坚持了约 1 天 23 小时后 GG ……

2020-10-27

因为 nt 模块的内存错误很可能来自其它驱动对内核模式存储的使用错误,所以继续关个别驱动排查。不过设置 Administrator 切换的时候终于出现了一次不是 nt 模块的蓝屏,这回是 iacamera64.sys ,看来是相机驱动的锅?但是卸载禁用了还是照旧其它蓝屏。可能只是偶然现象。

2020-10-29

排查驱动无果,忍无可忍打算退回 1803 ,但是没 Surface 系统映像(官网 Surface Book 2 给 1809 和 1803 的,但下载都以 KiB/s 计)所以还是得找通用 ISO 映像。结果发现 ISO 下载奇卡无比,BT 根本没速度(度盘就算了,离线还卡半天 99% )。好在https://blog.csdn.net/weixin_43314519/article/details/106184232有人分流了可以匿名直连的国内版 OneDrive 还有 3 个镜像地址。下载中途又蓝屏几次,有次下载了一半进度全作废,不过基本有 1.9MiB/s(用了 DownThemAll! 加上镜像)。但是下载了进恢复模式全新安装居然装了一半失败……后来验了 SHA1 文件是错的,看来这这机器缓存已经坑到下载文件都不靠谱了。换机单地址重下,1.4MiB/s 也还行,这回重装正常。

正设置新系统,又 MEMORY_CORRUPTION 蓝屏了……说不定硬件都有问题了,打算买新机器。看了下暂定 ROG 幻14 带灯的顶配,和 SB 2 大小重量差不多但是 R9 4900HS 很 YES ,更主要是店家能扩展 RAM 40G 一次到位。

至于这个破 SB2 嘛……不管了,先果断重新恢复扔 Windows.old 里的 20H9 (修复命令行模式进本机 MSYS2 bash 手动 mv ,应该没漏,光 mv 应该也没权限坑)。至少新机器到货前先撑几天。

2020-10-30

搞了半天好不容易 MediaCreationTool 做了 ISO 镜像打算覆盖重装修复,发现 20H2 不能原地覆盖升级,大概是因为 19042 比 19041 新的关系……

结果启动后又各种抽风(搞不好真是硬件坏了)。

首先是 Windows 商店和商店应用全部阵亡不说(设置了开机自启的便笺没过几秒闪退,Office 365 全员闪退),开始菜单直接挂了一点就对话框要求注销(当然是无用的,重启也无效;更坑的是不干掉 explorer.exe 这对话框还干不掉),就连桌面右下角操作中心面板(以前无效经常右键菜单打开就行了)和设置之类的自带应用都打不开了。虽然只有主要用户是这样,但还是不爽。Powershell 重新部署无用。(只有新版 Edge 是一直正常的。)

SFC /SCANNOW 还真发现有错,但恢复了还是抽风。DISM 没能用的 20H2 映像(因为之前是 Windows 易升升级上来的)……于是开 fsutil 设置允许遵循链接,创建符号链接到远程机器里的事先符号链接到 C:\Windows 的目录链接当 DISM 的 source 。那个是 2004 的系统(因为没别的 20H2 的实例),还真显示修复成功了。便笺、开始菜单和操作中心之类的都能用了,但是商店仍然抽风。最抽的是搜索点击任务栏搜索按钮或者开始菜单弹出后键盘输入都毫没反应,根本调不出来。

干掉 %LOCALAPPDATA%\Packages 里的对应数据,Powershell 再重新部署了数次( ShellExperienceHost.exe 单独接着 taskkill 后部署免得提示被占用,那个名字里带 CBS 一看就不好惹的结束不掉没法替换资源,看来没办法),终于修复(重置)了 Windows 商店和照片之类的其它自带应用。但是 Surface、Xbox 控制台小帮手什么的和其它一些非系统应用包括 Office 365 还是都不行,看来得重新商店里下载。没用到的一些应用趁机卸载清理了。

顺带手动 Remove-AppX 掉了传说中 2004 以来就没卵用的 Cortana :

image

但对搜索怎么操作都没反应的问题毫无帮助。最后还又通过批量 Add-AppXPackage 重置回来了,还多了个开机错误:

image

因为是开机一次性的,又还有更重要的问题要解决,先忍了。

类似的还有别的应用的错误,但重装应用后都解决了。

中间还有桌面右键菜单没有反应的问题(其实是卡了几分钟才弹出来)。删掉注册表 HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers 里导致卡顿的项解决。发现问题是 NV 面板,安装应该没问题一直也没碰(之前排查驱动停用的应该也都复原了),看来已经抽风到到了随机损坏文件的地步了吗……

最无语的是,过了半小时之后搜索莫名其妙恢复正常了……(不过,第一次搜索的标题上各个标签是中文,第二次打开就是英文了。这个先无视,反正应用商店几次更新后都是几乎全搞成英文版了,这次界面上反倒还有些中文。)

而更抽风的是,过了一会儿,下载了反馈中心之后(磁贴还是之后才正常的),商店里就再也下载不了了,全是 80072F8F 错误,连带 Windows 更新也连接不上……而且包括其它用户(用的 Administrator )和新建桌面的用户(偷懒启用了 sshd ),是整个系统全面抽风。试了下 2004 的那台机器是正常的,看来是本机的特定连接问题。

image

搜索错误号(不管是百度还是 Google )当然是例行没用的(即便错误的场景并没发散),反映出来的都是什么各种语言的时间错误的垃圾。这个错误实际上是 ERROR_INTERNET_DECODING_FAILED 或者 WININET_E_DECODING_FAILED ,改时间撑死就是只是应付 SSL 抽风的情况。倒是反馈应用里居然还有往前改一年时间能用的说法,看来还有微软的 bug ……但是我这里往前改了一年时间照样没用,又改回来了。

又找了半天,发现 Microsoft 论坛上一样还是各种对牛弹琴油盐不进的反馈回复外,难得还有个(看起来)有用的线索 。不过遗憾的是看注册表我这里看起来原来就是正常的,用 IISCrypto 按里面的 Best Practice 设置重启后一样无效,手动把注册表改回来了。

用 Sysinternals 的 procmon 跟了下发现跟更新终结点的连接似乎没有问题,Wireshark 抓包也没看出问题。只能先放置。

另外之前设置 %LOCALAPPDATA%\Packages 时长了个心眼特别注意把里面的 Debian 发行版路径保留了(指向里面的 rootfs\home 的子目录的快捷方式在迁移 Windows.old 后能用,看来 Windows 升级安装程序还自动维护路径)。不过里面的 LocalState 转移到外面软连接过去无法用,不管是执行 %WINDIR%\System32\bash.exe 还是 wsl.exe 都报找不到文件的错。先前不确定是商店应用集体抽风导致不能用的原因,还是先老实改回来了,发现能用,看来就是这个问题。

顺便把 %LOCALAPPDATA%%APPDATA% 里的 NTFS 压缩和存档属性都取消了,费了不少时间。无责任猜想:如果缓存有问题,关掉 NTFS 压缩会不会更好点?仔细想了下,这几台出问题的机器看来都有不少 NTFS 压缩文件。

2020-10-31

关掉 NTFS 压缩当然也不保证彻底(有些系统文件管不到),而且逻辑上还是只能减小而不是避免系统缓存的使用。果不其然,早上 WSL 里多编译了几个小的程序,还是挂了。

偶然点开了设置应用里的激活页面,发现激活信息没显示。运行 slmgr /dlv 出错:

image

看起来背后的原因是和 Powershell 重置系统应用时发现个别的所谓的“终结点映射器中没有更多的终结点可用”的问题一样(进恢复模式命令提示符里面——现在的版本 1803 ——提示“内存资源不足”,看来也是一样)。这个含糊的错误提示来自该死的没事找抽型 IDispatch ,逻辑上的线索又断了。

就 20H2 不能覆盖升级安装的问题,找到的新出炉的德语解决方案,里面提到的原因和我想的一样。死马当活马医,先再试试……

安装 5% 后……

image

好在起码日志有官方文档。在 C:\$windows.~bt\Sources\Panther\diagerr.xml 里找到了错误 0x8007025D 。参考类似的情况。盲猜可能是介质问题。于是用移动硬盘里的 ISO 镜像文件挂载代替复制到硬盘里的安装源,正常完成引导前的复制,继续更新。然而之后还是出错回滚,自动重启后:

image

重来,到 6% 蓝屏 KERNEL_SECURITY_CHECK_FAILURE 。这个算看脸,再重来:

image

……

之前脑子抽风+懒得切换管理员用户偷懒,居然没想到验证映像时计算多个 hash 根本就是浪费时间,HashMyFiles 就 40MiB/s+ 连 USB 3 移动机械硬盘的瓶颈都没碰到……早知老实用管理员控制台 sha1sum 了。

首先设备管理器关了主硬盘写缓存,复制了几次,确定主硬盘上的安装源的文件 hash 确认是和移动硬盘中的 ISO 映射的文件相同。虽然有进一步损坏的风险,内置 SSD 能比外置机械硬盘顺序读写快几倍,省时间更重要。主要的问题就是 sources\install.esd 这个大文件(虽说 ESD 压缩后 4G 已经比 WIM 小了还是很浪费时间)。资源管理器 WinRAR 什么的几次复制出来 hash 都不对,一次控制台 copy 就成功了。

2020-11-01

在浪费若干次 Windows 程序安装擦写硬盘无用功后,发现安装程序复制的 $WINDOWS.~BT\Sources\Install.esdsources\install.esd 大小相同但内容不同。执行 SetupHost% 的前 5% 实际上主要就是在复制这个文件。所以试着复制完 suspend 安装进程,然后手动复制和 hash 确认是和移动硬盘中的 ISO 映射的文件类似的方法避免重复完整安装。这次元气不太好,各种复制折腾了十几遍才 hash 对。之后安装终于成功了。然而,指望重装系统的主要问题一个都没解决,不管是开机参数错误弹窗、更新错误还是蓝屏。

image

……好吧,唯一发现有点区别的是 slmgr.vbs /dli 的结果。

image

心累,弃疗,等新机器。

FrankHB commented 1 year ago

重装几次 Win11 问题依旧。受不了无法安装商店应用,store.rg-adguard.net 凑数。

直到前几天重置系统清空了 C: ,终于正常了(不再 80072F8F 了),数年以来的告一段落。

看来根本还是软件问题。至今仍然不明白到底是哪里的权限炸了。

(中间偶有蓝屏比如 WSL1 bug 略。)

ice1000 commented 1 year ago

推荐使用 Linux

y1yang0 commented 1 year ago

催更

FrankHB commented 7 months ago

借个地方 原文出处

凭什么这些预期的性质就必须是通过拼凑组合某些预置的、随项按硬编码特设规则传染得到的类型,而不是由用户直接以语言中的计算规则表达何为预期性质的、不必然依赖具体的项的元数据来表达?

按照这里的讨论(里面很多内容,需自行查阅),有人写了文章介绍了一些历史概念(譬如系统调用)为什么要初步地设计成为一个单独的模块。我猜测,这样子的历史惯性会让大家相信很多事物靠模块化能更轻松地达到结果。我其实很想了解你对这种现象的看法。

现有 issue 的坑太深了,单独开一个新的吧。