每年的三四月份都是春招旺季Windows开发岗的笔试题总是被大家吐槽“又杂又偏”。前阵子整理资料时翻到了360公司2018春招的Windows开发工程师客观题合集重新做了一遍发现即便是放到现在这套题的知识点覆盖依然很能打。它不光是考API调用而是把C/C功底、Windows底层机制、安全编程思维、PE结构这些硬核内容全揉在了一起。对于准备面试Windows方向岗位的朋友来说这套题是一份很好的自检清单。这篇文章我不打算逐题贴答案而是把这套题背后涉及的核心知识体系拆开揉碎讲清楚每类题目在考什么、为什么这么考、实际开发中对应什么场景。如果你正在准备面试或者想系统梳理自己的Windows知识树这篇文章应该能帮你省不少时间。1. 笔试全景岗位定位与考察思路1.1 360招Windows开发到底想要什么样的人先聊聊这套题背后的岗位定位。360的业务以安全起家它的Windows开发工程师岗位跟普通业务型公司的同类岗位有明显区别。普通公司可能更看重你能否熟练调用Win32 API写业务逻辑能否快速上手MFC或Qt搭界面但360这类安全厂商关注的是你对系统底层机制的理解深度因为内核驱动开发、进程注入防御、hook检测、文件系统过滤这些安全工作全都建立在对Windows内部运行机制的精通之上。这套客观题合集的覆盖面也印证了这一点。题目大致分布在几个域C/C语言基础与内存模型、进程与线程同步、Windows消息机制、DLL与PE结构、系统API底层行为、网络编程基础、编码与字符集问题。这个分布本身就在传递一个信号他们需要的是“懂系统的C/C程序员”而不是只会拖控件的客户端开发。1.2 客观题这个形式的考察逻辑客观题选择题为主在技术笔试中一直有争议很多人觉得背题就能过。但把360这套题认真做一遍会发现它的客观题很多是“多选逆向选择”干扰项设计得很有水平。它不是考你“知不知道这个API存在”而是考你在多个看似都合理的选项中能不能识别出那个真正符合Windows内部行为的答案。举个例子涉及到进程句柄表、内核对象引用计数这类题目如果你只是背过“CloseHandle用来关闭句柄”但不理解句柄与内核对象之间的映射关系、不清楚关闭句柄与对象销毁之间的区别你很难选对。这种出题思路其实是在筛选“真正写过底层代码、调试过系统问题”的人而不是靠刷题能短期速成的。所以我的建议是刷这套题重点不是记答案而是把每个选项背后的机制吃透。2. C/C与内存管理躲不开的地基2.1 指针、数组与内存布局的经典陷阱Windows开发工程师的笔试题里C/C基础永远是重头戏。360这套题里指针相关题目占了相当比例而且考察角度比普通C题目更贴近系统底层。比如数组名与指针的区别、多维数组的内存布局、指针类型转换后的运算步长这些题目刷下来我觉得最有价值的是帮助建立“内存视角”的编程思维。看一个典型的考察点int a[5]a和a的值相同但类型不同a1跳过一个int4字节a1跳过整个数组20字节。这个点在C语言课上老师讲过但很多人写代码时根本没当回事。然而在Windows开发中这种指针运算直接关系到缓冲区处理是否正确。比如你用ReadFile读取数据到栈上缓冲区然后对缓冲区内存做偏移计算时一旦类型搞错轻则读错数据重则栈溢出被利用。再一个高频考点是结构体对齐。#pragma pack的用法、默认对齐规则按结构体成员中最大对齐数的整数倍对齐、32位与64位下sizeof结果的差异。Windows API里大量结构体如OVERLAPPED、WNDCLASSEX都涉及对齐。早年我在处理跨进程共享内存时就是因为没注意对齐规则32位程序写入的结构体数据被64位程序读取时直接错位排查了很久才发现是sizeof在两个平台下算出来的长度不一致。所以遇到这类的题目别只记答案建议自己写个demo分别在Win32和x64下打印sizeof结果感受会更直观。2.2 堆与栈、内存分配策略的底层差异堆与栈的区别在Windows岗笔试中也是必考项。表面问题是“堆和栈谁的分配速度快、谁需要手动释放”但更深层的考察是你是否理解栈内存的高地址向低地址增长、函数调用帧的建立与销毁、堆内存由堆管理器维护的数据结构。我建议备考时把这两个问题彻底搞清楚。第一栈上局部变量的生命周期与作用域强绑定返回栈上指针就是未定义行为第二堆内存分配HeapAlloc、malloc、new背后涉及堆管理器在空闲链表、页表项上的操作频繁的小块堆分配会产生碎片。在Windows下写长时间运行的服务程序时堆碎片化问题很要命可能你内存总量还够但分配大块连续内存时会失败。360这类软件常驻后台对内存碎片的敏感度很高笔试题里考堆栈说明他们确实关心你写出来的代码在长时间运行下的稳定性。另外VirtualAlloc与HeapAlloc的区别也是常客。VirtualAlloc直接以页4KB为粒度保留和提交虚拟内存主要用于大型内存分配、可执行内存配合PAGE_EXECUTE_READWRITE或者自定义内存管理器的场景。而HeapAlloc是堆管理器在虚拟内存之上提供的小粒度分配接口。很多注入类样本会通过VirtualAlloc分配可执行内存所以安全软件在做内存扫描时会对PAGE_EXECUTE_READWRITE属性的内存区域特别敏感。理解这层关系对后续理解安全相关的行为检测逻辑很有帮助。2.3 宏定义、const与类型安全的深坑客观题里宏定义的题目也很典型。#define SQUARE(x) x*x传SQUARE(12)得几答案是5而不是9。这个经典坑考察的是宏展开的纯文本替换本质。另一个高频陷阱是#define定义的类型别名与typedef的区别比如#define CHAR_PTR char* CHAR_PTR p1, p2; // p1是char*p2是char而写成typedef char* CHAR_PTR;则CHAR_PTR p1, p2;两个都是指针。这种细节在Windows开发里很常见比如LPCTSTR这类类型别名如果不懂底层定义跨平台编译时会踩很多坑。现在的C工程规范普遍推荐用constexpr或const替代无参宏用using别名替代typedef和带参宏。但在老代码尤其是Windows SDK的众多头文件里宏仍然是基础设施。你要学会跟它共存。笔试中遇到宏题目我的经验是先把宏展开成最原始的文本再按C语法分析千万不要脑补任何逻辑。3. Windows核心机制从消息循环到内核对象3.1 消息循环与窗口机制的理解深度Windows消息机制是Win32开发的基础中的基础客观题里几乎必考。问题通常集中在消息队列分为哪几种、SendMessage与PostMessage的区别、GetMessage与PeekMessage的返回值含义、WM_PAINT何时产生。我重点解释一个容易理解错的点SendMessage是同步的它会直接调用目标窗口的窗口过程跨线程时会通过系统内部机制切换上下文直到消息处理完成才返回而PostMessage是把消息放入目标线程的消息队列后立即返回属于异步操作。这个区别在实际开发中直接关系到死锁风险。比如A线程用SendMessage给B线程发消息B线程又用SendMessage给A线程发消息而且两边都在等待对方返回就形成了死锁。在UI线程与工作线程交互时这是Windows开发最经典的死锁场景之一。还有WM_PAINT。很多人以为它是系统主动发过来的“绘制通知”其实更准确地说它是一个低优先级消息。只有当消息队列为空时系统才可能合成WM_PAINT。而且如果用InvalidateRect标记部分区域无效BeginPaint拿到无效区域系统还会做区域的合并优化。笔试里考这部分通常不是死记硬背能搞定的。建议在写一个简单的Win32窗口程序时在WndProc里加OutputDebugString打印消息顺序实操一遍就能理解透彻。3.2 进程与线程的同步原语多线程同步的客观题是拉开差距的地方。360这套题里CriticalSection、Mutex、Semaphore、Event的区别是高频题还会追问它们在内核态与用户态间的切换成本。核心理解是CriticalSection临界区对象是用户态同步原语线程在等待临界区时会在用户态自旋或短暂切换到内核态等待因此当锁竞争不激烈时性能很好Mutex、Semaphore、Event都是内核对象等待它们时线程会进入内核态等待切换成本高但支持跨进程同步也支持超时控制。实际工程里的选型逻辑是如果只在进程内部做线程互斥优先用临界区Windows Vista以后的SRWLock性能更好偏向读多写少的场景如果需要跨进程同步比如多个进程同时操作一个共享文件就用Mutex如果需要控制资源数量比如线程池限制并发数用Semaphore如果只是通知某个事件发生比如后台线程完成网络请求用Event。另外volatile到底能不能用于多线程同步也是这套题里经常绕不开的点。在C11之前Windows下volatile带有“每次读写都从内存访问”的语义但现代C标准中volatile并不保证原子性也不提供内存屏障。比如两个线程对一个volatile int执行操作结果仍然可能错乱。正确的做法是用std::atomic或Interlocked系列函数。备考时如果能结合InterlockedIncrement、InterlockedCompareExchange这类Windows API去理解原子操作对后续理解无锁数据结构也很有帮助。3.3 内核对象与句柄表内核对象与句柄的关系对新手来说比较抽象。内核对象是操作系统内核维护的数据结构进程、线程、事件、互斥体、文件映射等都属于内核对象而句柄是你手里的一个索引值通过它你可以访问对应的内核对象。这个机制里有个考点句柄表是进程级的概念。A进程拿到的句柄值在B进程里大概率是无效的除非通过继承或DuplicateHandle显式复制。所以跨进程共享核心对象时不能直接传句柄值。相关典型场景是进程间通信或同步时需要把命名内核对象如CreateMutex(NULL, FALSE, Global\\MyMutex)通过名字共享给其他进程。还有一个高频题点创建内核对象的函数如CreateThread返回的句柄与直接返回的指针有什么区别。CreateThread返回的是线程句柄不是线程ID也不是指针。句柄引用内核中的线程对象线程对象在句柄关闭前不会被销毁。如果忘记CloseHandle每次创建线程就泄漏一个内核对象引用长期运行会导致系统资源耗尽。这类题目看上去是在考API的记忆实际上是通过句柄与对象生命周期考察你是不是真的懂Windows资源管理的底层逻辑。3.4 DLL与PE结构安全方向的核心考点在360的笔试里DLL和PE结构的分量比一般的公司高得多这与安全业务强相关。我见过不少普通应用开发的题集DLL部分就考一下LoadLibrary和GetProcAddress的用法但360的题目会更深入导出表、导入表、重定位表、DllMain的加载时机和线程通知限制。先说DllMain。系统的加载器在进程初始化、新线程创建、线程退出、进程销毁时会调用DLL的入口点并传入相应的fdwReason。笔试里经常考的是在DllMain里能不能创建线程、能不能调用LoadLibrary。答案是不要这么做。原因在于DllMain调用期间系统加载器锁loader lock被持有如果在DllMain里再调用LoadLibrary加载另一个DLL很可能触发递归加载或者死锁。微软官方文档也明确提示在DllMain中只能做简单的初始化工作。很多崩溃现场就是因为在DllMain里做了过重的逻辑。再说PE结构。笔试中可能给出一个PE文件的节区表问某个RVA属于哪个节或者让你计算某个导出函数的入口地址。AddressOfEntryPoint、ImageBase、SizeOfImage、Import Address TableIAT这些字段的概念要搞熟。映射到安全领域的实际场景进程注入的一种常见手法是修改目标进程IAT让目标进程调用系统API时先执行攻击代码。所以安全软件在做行为检测时会重点校验关键API的入口地址是否被篡改。如果你在准备这类岗位我强烈建议你装一个PE-bear或CFF Explorer随便找一个exe文件打开把这几个关键字段和各个节.text、.data、.rdata、.reloc在内存中的映射关系手动捋一遍。笔试中那些看似抽象的字段在工具里其实都是看得见摸得着的。4. 与Windows环境密切相关的开发陷阱4.1 字符集与中文乱码问题最近搜索热词里“windows乱码大全”被反复提及这确实也是Windows开发中最常见的问题之一。笔试中对应考点是char多字节编码与wchar_t宽字符编码的区别、ANSI代码页与UnicodeUTF-16/UTF-8的关系、TCHAR宏的适配逻辑。在Windows平台上char*字符串的具体编码依赖于当前系统代码页简体中文系统是GBK即936代码页而wchar_t*在Windows下固定是UTF-16小端存储。所以在源文件中保存为UTF-8的char*字面量如果直接在简体中文系统里当GBK处理就会显示为乱码。这也是为什么VS里会出现“无法用代码页936识别的字符”之类的警告。正确做法是源文件统一用带BOM的UTF-8存储对外传输和存储优先用UTF-8Windows API内部接口调用优先使用宽字符版本比如CreateFileW而不是CreateFileA。很多人在处理控制台程序的输出乱码时习惯用SetConsoleOutputCP(CP_UTF8)。这本质上只是改变了控制台编码映射并没有改变字符串本身的编码。理解了字符集才知道问题不是出在输出这一刻而是出在字符串的“出生”阶段——它到底是用什么编码产生出来的。4.2 命令行脚本与Windows系统管理热词里有不少关于命令行脚本、批处理优化、静默运行的提问。这些内容本身不一定会直接出现在笔试题中但它们是Windows开发工程师的日常“辅助技能”。比如用bat或PowerShell脚本做构建、部署、环境修复是每个客户端开发都绕不开的事。我在这里补充一些批处理的实际经验。如果你要写一个开机自启的服务或程序调试脚本sc create与sc start配合使用最方便。要隐藏命令行窗口运行某程序可以用powershell -WindowStyle Hidden -Command Start-Process xxx.exe。清理临时文件时注意别粗暴删C:\Windows\Temp下的文件很多文件正在被占用建议先判断再删。系统优化的bat脚本里调整电源模式用powercfg /setactive SCHEME_MIN节能或SCHEME_BALANCED平衡高性能模式是SCHEME_MIN其实是卓越性能具体名称可用powercfg /list查看。这些经验看起来不起眼但在实际运维和调试环境中非常实用。笔试不一定考但面试官如果问“你平时怎么排查Windows环境问题”能流畅说出几个脚本化的处理手段会是明显的加分项。4.3 版本兼容与系统补丁的坑热词里有两处提到了驱动签名验证的问题“Windows无法验证此设备所需的驱动程序的数字签名”。这类问题在Windows 11上尤其常见动不动就提示驱动数字签名失效。实际上主板开启了Secure Boot时内核模式的驱动必须通过微软签名认证。测试自己的驱动时可以通过“高级启动-疑难解答-启动设置-禁用驱动程序强制签名”来临时关闭但正式发布前必须将驱动提交给微软进行WHQL签名。对笔试而言版本兼容性题目大概率会涉及Windows API在不同版本间的差异比如SetProcessDEPPolicy在32位系统上的可用性限制。更深的考点是你知不知道用GetProcAddress动态获取API入口、用系统版本API而不是直接查看注册表来判断版本这类常规操作。2018年时的系统主流是Windows 7与Windows 10并存360的产品要同时兼容这两个版本所以笔试里考察旧版API的兼容行为也在意料之中。现在到了Windows 11时代这个问题依然重要甚至更复杂因为ARM版Windows又带来了一批新的API差异。5. 网络编程与系统编程的相通点5.1 Socket编程与阻塞非阻塞的考察重点Windows开发岗的笔试通常也会放几道网络编程基础题进去因为客户端开发免不了与服务器交互、上传下载数据。考察重点集中在WSAStartup的初始化、socket的阻塞与非阻塞模式、select模型与WSAEventSelect、重叠I/OOverlapped I/O与IOCP的基本概念。对普通岗位来说能分清阻塞与非阻塞即可。阻塞模式下recv如果没数据线程就卡住非阻塞模式会直接返回WSAEWOULDBLOCK需要你用select去判断套接字何时可读、可写。对360这类公司来说他们的产品可能要同时维护大量连接比如下载加速、云查杀通信所以客观题里出现IOCP的概念题也不意外。IOCP是Windows下最高效的异步I/O模型内部依赖完成端口Completion Port来避免每连接一线程的开销。如果备考时间充足建议把WSARecv与IOCP配合使用的流程代码至少手写一遍。5.2 编码转换与网络字节序网络编程题中的小陷阱是字节序。Windows x86/x64是little-endian而网络字节序是big-endian。所以htons、htonl、ntohs、ntohl这些API是做网络通信时的标配。笔试题很喜欢出一段代码让你判断端口号转换是否正确。另一个容易犯错的是字符串编码在网络传输中的处理。很多协议传输按UTF-8编码但Windows下本地字符串可能是UTF-16。发送时要用WideCharToMultiByte把宽字符转为UTF-8字符串接收后用MultiByteToWideChar转回wchar_t。如果直接丢去传输接收端的解码器很可能因为BOM缺失或编码不匹配而乱码。Windows乱码问题中很大一部分就来源于此跟前面说的字符集知识点其实是同一个体系。5.3 客户端与服务端联调的经验日常开发里网络层的坑更多出现在联调环节。最常见的问题之一客户端发送了数据服务端半天收不到完整包。原因通常是TCP是流式协议数据无边界需要应用层协议自己去切分包。笔试中这类题目一般不会考到但在项目经验中却很常见。我的做法是在协议设计时统一采用“包头4字节长度字段网络字节序包体”的TLV结构。若用C序列化库推荐直接引入protobuf或者flatbuffers没必要自己造轮子。6. 备考体验与实操复盘6.1 刷题之外如何真正巩固Windows知识把这套题从头到尾过完一遍之后我的体会是题目本身只是索引延伸出去的知识体系才是重点。如果你只刷题不做实验那这些知识点就是点状记忆过两周就忘如果你每遇到一个知识点都动手写一个几十行的demo去验证那这些点才会逐渐连成网。举个例子原子操作相关的题目你可以写一个多线程下的计数器程序先用普通int再用InterlockedIncrement观察两种写法在多个线程同时运行时结果的差异。如果你进一步在性能分析工具下观察锁竞争对执行时间的影响那就更好了。Windows开发的知识密度很高学习路径必须“边学边码”。实操工具方面我推荐几个Process Explorer查看进程句柄和内核对象、DebugView捕获OutputDebugString输出、WinDbg用户态和内核态调试、API Monitor监控进程的API调用。这些工具不光对笔试有帮助也是日常工作排查问题的利器。6.2 做题时的策略与常见失分点客观题的做题策略也有一些经验可谈。360这套题里的多选题少选一般不给分或给部分分错选不给分所以拿不准的选项宁可不选。题目文字里出现“错误的一项是”“不包括”“除了”这类否定词时建议把否定词圈出来这是最常见的失分点。答案模棱两可时优先选择符合Windows官方文档描述的选项而不是符合“自己经验”的选项。比如有些老程序员习惯用printf但官方环境下早就建议使用OutputDebugString或资源文件配MessageBox了。笔试选择题依据的是官方定义和行为而不是个人编码习惯。时间分配上建议先把有把握的题做完再回头啃难题。整套题客观题数量不小如果在一道指针题上耗太久后面网络或线程同步的题可能来不及做。这些都是我实际考试时踩过的坑。6.3 从笔试看岗位什么样的候选人更容易通过最后总结一下这类笔试题背后潜藏的人才标准。在我看来360这类公司要找的Windows开发工程师必须具备这样的能力能理解Windows系统机制而不只是会调用API有良好的C/C功底对内存布局、指针、结构体对齐、编码转换有肌肉记忆具备安全敏感度知道攻击者可能利用哪些系统机制做手脚能排查实际环境中的问题而不只是写“能编译”的代码。如果这套题你做得比较顺说明Windows方向的基础知识储备是合格的接下来可以针对简历上的项目做深挖准备。如果做得吃力也不要太焦虑把上面提到的知识块逐个填充起来再把每个知识点对应的实验代码写一遍面这类岗位是完全来得及的。这套题我自己刷下来的心得是Windows开发最吸引人的地方恰恰就在于它足够底层、足够有挑战性。每当你搞清楚一个系统机制的来龙去脉整个知识树就会更茂盛一点。希望这篇拆解能帮你把零散的笔试知识点串成体系祝各位春招顺利。
每年的三四月份都是春招旺季Windows开发岗的笔试题总是被大家吐槽“又杂又偏”。前阵子整理资料时翻到了360公司2018春招的Windows开发工程师客观题合集重新做了一遍发现即便是放到现在这套题的知识点覆盖依然很能打。它不光是考API调用而是把C/C功底、Windows底层机制、安全编程思维、PE结构这些硬核内容全揉在了一起。对于准备面试Windows方向岗位的朋友来说这套题是一份很好的自检清单。这篇文章我不打算逐题贴答案而是把这套题背后涉及的核心知识体系拆开揉碎讲清楚每类题目在考什么、为什么这么考、实际开发中对应什么场景。如果你正在准备面试或者想系统梳理自己的Windows知识树这篇文章应该能帮你省不少时间。1. 笔试全景岗位定位与考察思路1.1 360招Windows开发到底想要什么样的人先聊聊这套题背后的岗位定位。360的业务以安全起家它的Windows开发工程师岗位跟普通业务型公司的同类岗位有明显区别。普通公司可能更看重你能否熟练调用Win32 API写业务逻辑能否快速上手MFC或Qt搭界面但360这类安全厂商关注的是你对系统底层机制的理解深度因为内核驱动开发、进程注入防御、hook检测、文件系统过滤这些安全工作全都建立在对Windows内部运行机制的精通之上。这套客观题合集的覆盖面也印证了这一点。题目大致分布在几个域C/C语言基础与内存模型、进程与线程同步、Windows消息机制、DLL与PE结构、系统API底层行为、网络编程基础、编码与字符集问题。这个分布本身就在传递一个信号他们需要的是“懂系统的C/C程序员”而不是只会拖控件的客户端开发。1.2 客观题这个形式的考察逻辑客观题选择题为主在技术笔试中一直有争议很多人觉得背题就能过。但把360这套题认真做一遍会发现它的客观题很多是“多选逆向选择”干扰项设计得很有水平。它不是考你“知不知道这个API存在”而是考你在多个看似都合理的选项中能不能识别出那个真正符合Windows内部行为的答案。举个例子涉及到进程句柄表、内核对象引用计数这类题目如果你只是背过“CloseHandle用来关闭句柄”但不理解句柄与内核对象之间的映射关系、不清楚关闭句柄与对象销毁之间的区别你很难选对。这种出题思路其实是在筛选“真正写过底层代码、调试过系统问题”的人而不是靠刷题能短期速成的。所以我的建议是刷这套题重点不是记答案而是把每个选项背后的机制吃透。2. C/C与内存管理躲不开的地基2.1 指针、数组与内存布局的经典陷阱Windows开发工程师的笔试题里C/C基础永远是重头戏。360这套题里指针相关题目占了相当比例而且考察角度比普通C题目更贴近系统底层。比如数组名与指针的区别、多维数组的内存布局、指针类型转换后的运算步长这些题目刷下来我觉得最有价值的是帮助建立“内存视角”的编程思维。看一个典型的考察点int a[5]a和a的值相同但类型不同a1跳过一个int4字节a1跳过整个数组20字节。这个点在C语言课上老师讲过但很多人写代码时根本没当回事。然而在Windows开发中这种指针运算直接关系到缓冲区处理是否正确。比如你用ReadFile读取数据到栈上缓冲区然后对缓冲区内存做偏移计算时一旦类型搞错轻则读错数据重则栈溢出被利用。再一个高频考点是结构体对齐。#pragma pack的用法、默认对齐规则按结构体成员中最大对齐数的整数倍对齐、32位与64位下sizeof结果的差异。Windows API里大量结构体如OVERLAPPED、WNDCLASSEX都涉及对齐。早年我在处理跨进程共享内存时就是因为没注意对齐规则32位程序写入的结构体数据被64位程序读取时直接错位排查了很久才发现是sizeof在两个平台下算出来的长度不一致。所以遇到这类的题目别只记答案建议自己写个demo分别在Win32和x64下打印sizeof结果感受会更直观。2.2 堆与栈、内存分配策略的底层差异堆与栈的区别在Windows岗笔试中也是必考项。表面问题是“堆和栈谁的分配速度快、谁需要手动释放”但更深层的考察是你是否理解栈内存的高地址向低地址增长、函数调用帧的建立与销毁、堆内存由堆管理器维护的数据结构。我建议备考时把这两个问题彻底搞清楚。第一栈上局部变量的生命周期与作用域强绑定返回栈上指针就是未定义行为第二堆内存分配HeapAlloc、malloc、new背后涉及堆管理器在空闲链表、页表项上的操作频繁的小块堆分配会产生碎片。在Windows下写长时间运行的服务程序时堆碎片化问题很要命可能你内存总量还够但分配大块连续内存时会失败。360这类软件常驻后台对内存碎片的敏感度很高笔试题里考堆栈说明他们确实关心你写出来的代码在长时间运行下的稳定性。另外VirtualAlloc与HeapAlloc的区别也是常客。VirtualAlloc直接以页4KB为粒度保留和提交虚拟内存主要用于大型内存分配、可执行内存配合PAGE_EXECUTE_READWRITE或者自定义内存管理器的场景。而HeapAlloc是堆管理器在虚拟内存之上提供的小粒度分配接口。很多注入类样本会通过VirtualAlloc分配可执行内存所以安全软件在做内存扫描时会对PAGE_EXECUTE_READWRITE属性的内存区域特别敏感。理解这层关系对后续理解安全相关的行为检测逻辑很有帮助。2.3 宏定义、const与类型安全的深坑客观题里宏定义的题目也很典型。#define SQUARE(x) x*x传SQUARE(12)得几答案是5而不是9。这个经典坑考察的是宏展开的纯文本替换本质。另一个高频陷阱是#define定义的类型别名与typedef的区别比如#define CHAR_PTR char* CHAR_PTR p1, p2; // p1是char*p2是char而写成typedef char* CHAR_PTR;则CHAR_PTR p1, p2;两个都是指针。这种细节在Windows开发里很常见比如LPCTSTR这类类型别名如果不懂底层定义跨平台编译时会踩很多坑。现在的C工程规范普遍推荐用constexpr或const替代无参宏用using别名替代typedef和带参宏。但在老代码尤其是Windows SDK的众多头文件里宏仍然是基础设施。你要学会跟它共存。笔试中遇到宏题目我的经验是先把宏展开成最原始的文本再按C语法分析千万不要脑补任何逻辑。3. Windows核心机制从消息循环到内核对象3.1 消息循环与窗口机制的理解深度Windows消息机制是Win32开发的基础中的基础客观题里几乎必考。问题通常集中在消息队列分为哪几种、SendMessage与PostMessage的区别、GetMessage与PeekMessage的返回值含义、WM_PAINT何时产生。我重点解释一个容易理解错的点SendMessage是同步的它会直接调用目标窗口的窗口过程跨线程时会通过系统内部机制切换上下文直到消息处理完成才返回而PostMessage是把消息放入目标线程的消息队列后立即返回属于异步操作。这个区别在实际开发中直接关系到死锁风险。比如A线程用SendMessage给B线程发消息B线程又用SendMessage给A线程发消息而且两边都在等待对方返回就形成了死锁。在UI线程与工作线程交互时这是Windows开发最经典的死锁场景之一。还有WM_PAINT。很多人以为它是系统主动发过来的“绘制通知”其实更准确地说它是一个低优先级消息。只有当消息队列为空时系统才可能合成WM_PAINT。而且如果用InvalidateRect标记部分区域无效BeginPaint拿到无效区域系统还会做区域的合并优化。笔试里考这部分通常不是死记硬背能搞定的。建议在写一个简单的Win32窗口程序时在WndProc里加OutputDebugString打印消息顺序实操一遍就能理解透彻。3.2 进程与线程的同步原语多线程同步的客观题是拉开差距的地方。360这套题里CriticalSection、Mutex、Semaphore、Event的区别是高频题还会追问它们在内核态与用户态间的切换成本。核心理解是CriticalSection临界区对象是用户态同步原语线程在等待临界区时会在用户态自旋或短暂切换到内核态等待因此当锁竞争不激烈时性能很好Mutex、Semaphore、Event都是内核对象等待它们时线程会进入内核态等待切换成本高但支持跨进程同步也支持超时控制。实际工程里的选型逻辑是如果只在进程内部做线程互斥优先用临界区Windows Vista以后的SRWLock性能更好偏向读多写少的场景如果需要跨进程同步比如多个进程同时操作一个共享文件就用Mutex如果需要控制资源数量比如线程池限制并发数用Semaphore如果只是通知某个事件发生比如后台线程完成网络请求用Event。另外volatile到底能不能用于多线程同步也是这套题里经常绕不开的点。在C11之前Windows下volatile带有“每次读写都从内存访问”的语义但现代C标准中volatile并不保证原子性也不提供内存屏障。比如两个线程对一个volatile int执行操作结果仍然可能错乱。正确的做法是用std::atomic或Interlocked系列函数。备考时如果能结合InterlockedIncrement、InterlockedCompareExchange这类Windows API去理解原子操作对后续理解无锁数据结构也很有帮助。3.3 内核对象与句柄表内核对象与句柄的关系对新手来说比较抽象。内核对象是操作系统内核维护的数据结构进程、线程、事件、互斥体、文件映射等都属于内核对象而句柄是你手里的一个索引值通过它你可以访问对应的内核对象。这个机制里有个考点句柄表是进程级的概念。A进程拿到的句柄值在B进程里大概率是无效的除非通过继承或DuplicateHandle显式复制。所以跨进程共享核心对象时不能直接传句柄值。相关典型场景是进程间通信或同步时需要把命名内核对象如CreateMutex(NULL, FALSE, Global\\MyMutex)通过名字共享给其他进程。还有一个高频题点创建内核对象的函数如CreateThread返回的句柄与直接返回的指针有什么区别。CreateThread返回的是线程句柄不是线程ID也不是指针。句柄引用内核中的线程对象线程对象在句柄关闭前不会被销毁。如果忘记CloseHandle每次创建线程就泄漏一个内核对象引用长期运行会导致系统资源耗尽。这类题目看上去是在考API的记忆实际上是通过句柄与对象生命周期考察你是不是真的懂Windows资源管理的底层逻辑。3.4 DLL与PE结构安全方向的核心考点在360的笔试里DLL和PE结构的分量比一般的公司高得多这与安全业务强相关。我见过不少普通应用开发的题集DLL部分就考一下LoadLibrary和GetProcAddress的用法但360的题目会更深入导出表、导入表、重定位表、DllMain的加载时机和线程通知限制。先说DllMain。系统的加载器在进程初始化、新线程创建、线程退出、进程销毁时会调用DLL的入口点并传入相应的fdwReason。笔试里经常考的是在DllMain里能不能创建线程、能不能调用LoadLibrary。答案是不要这么做。原因在于DllMain调用期间系统加载器锁loader lock被持有如果在DllMain里再调用LoadLibrary加载另一个DLL很可能触发递归加载或者死锁。微软官方文档也明确提示在DllMain中只能做简单的初始化工作。很多崩溃现场就是因为在DllMain里做了过重的逻辑。再说PE结构。笔试中可能给出一个PE文件的节区表问某个RVA属于哪个节或者让你计算某个导出函数的入口地址。AddressOfEntryPoint、ImageBase、SizeOfImage、Import Address TableIAT这些字段的概念要搞熟。映射到安全领域的实际场景进程注入的一种常见手法是修改目标进程IAT让目标进程调用系统API时先执行攻击代码。所以安全软件在做行为检测时会重点校验关键API的入口地址是否被篡改。如果你在准备这类岗位我强烈建议你装一个PE-bear或CFF Explorer随便找一个exe文件打开把这几个关键字段和各个节.text、.data、.rdata、.reloc在内存中的映射关系手动捋一遍。笔试中那些看似抽象的字段在工具里其实都是看得见摸得着的。4. 与Windows环境密切相关的开发陷阱4.1 字符集与中文乱码问题最近搜索热词里“windows乱码大全”被反复提及这确实也是Windows开发中最常见的问题之一。笔试中对应考点是char多字节编码与wchar_t宽字符编码的区别、ANSI代码页与UnicodeUTF-16/UTF-8的关系、TCHAR宏的适配逻辑。在Windows平台上char*字符串的具体编码依赖于当前系统代码页简体中文系统是GBK即936代码页而wchar_t*在Windows下固定是UTF-16小端存储。所以在源文件中保存为UTF-8的char*字面量如果直接在简体中文系统里当GBK处理就会显示为乱码。这也是为什么VS里会出现“无法用代码页936识别的字符”之类的警告。正确做法是源文件统一用带BOM的UTF-8存储对外传输和存储优先用UTF-8Windows API内部接口调用优先使用宽字符版本比如CreateFileW而不是CreateFileA。很多人在处理控制台程序的输出乱码时习惯用SetConsoleOutputCP(CP_UTF8)。这本质上只是改变了控制台编码映射并没有改变字符串本身的编码。理解了字符集才知道问题不是出在输出这一刻而是出在字符串的“出生”阶段——它到底是用什么编码产生出来的。4.2 命令行脚本与Windows系统管理热词里有不少关于命令行脚本、批处理优化、静默运行的提问。这些内容本身不一定会直接出现在笔试题中但它们是Windows开发工程师的日常“辅助技能”。比如用bat或PowerShell脚本做构建、部署、环境修复是每个客户端开发都绕不开的事。我在这里补充一些批处理的实际经验。如果你要写一个开机自启的服务或程序调试脚本sc create与sc start配合使用最方便。要隐藏命令行窗口运行某程序可以用powershell -WindowStyle Hidden -Command Start-Process xxx.exe。清理临时文件时注意别粗暴删C:\Windows\Temp下的文件很多文件正在被占用建议先判断再删。系统优化的bat脚本里调整电源模式用powercfg /setactive SCHEME_MIN节能或SCHEME_BALANCED平衡高性能模式是SCHEME_MIN其实是卓越性能具体名称可用powercfg /list查看。这些经验看起来不起眼但在实际运维和调试环境中非常实用。笔试不一定考但面试官如果问“你平时怎么排查Windows环境问题”能流畅说出几个脚本化的处理手段会是明显的加分项。4.3 版本兼容与系统补丁的坑热词里有两处提到了驱动签名验证的问题“Windows无法验证此设备所需的驱动程序的数字签名”。这类问题在Windows 11上尤其常见动不动就提示驱动数字签名失效。实际上主板开启了Secure Boot时内核模式的驱动必须通过微软签名认证。测试自己的驱动时可以通过“高级启动-疑难解答-启动设置-禁用驱动程序强制签名”来临时关闭但正式发布前必须将驱动提交给微软进行WHQL签名。对笔试而言版本兼容性题目大概率会涉及Windows API在不同版本间的差异比如SetProcessDEPPolicy在32位系统上的可用性限制。更深的考点是你知不知道用GetProcAddress动态获取API入口、用系统版本API而不是直接查看注册表来判断版本这类常规操作。2018年时的系统主流是Windows 7与Windows 10并存360的产品要同时兼容这两个版本所以笔试里考察旧版API的兼容行为也在意料之中。现在到了Windows 11时代这个问题依然重要甚至更复杂因为ARM版Windows又带来了一批新的API差异。5. 网络编程与系统编程的相通点5.1 Socket编程与阻塞非阻塞的考察重点Windows开发岗的笔试通常也会放几道网络编程基础题进去因为客户端开发免不了与服务器交互、上传下载数据。考察重点集中在WSAStartup的初始化、socket的阻塞与非阻塞模式、select模型与WSAEventSelect、重叠I/OOverlapped I/O与IOCP的基本概念。对普通岗位来说能分清阻塞与非阻塞即可。阻塞模式下recv如果没数据线程就卡住非阻塞模式会直接返回WSAEWOULDBLOCK需要你用select去判断套接字何时可读、可写。对360这类公司来说他们的产品可能要同时维护大量连接比如下载加速、云查杀通信所以客观题里出现IOCP的概念题也不意外。IOCP是Windows下最高效的异步I/O模型内部依赖完成端口Completion Port来避免每连接一线程的开销。如果备考时间充足建议把WSARecv与IOCP配合使用的流程代码至少手写一遍。5.2 编码转换与网络字节序网络编程题中的小陷阱是字节序。Windows x86/x64是little-endian而网络字节序是big-endian。所以htons、htonl、ntohs、ntohl这些API是做网络通信时的标配。笔试题很喜欢出一段代码让你判断端口号转换是否正确。另一个容易犯错的是字符串编码在网络传输中的处理。很多协议传输按UTF-8编码但Windows下本地字符串可能是UTF-16。发送时要用WideCharToMultiByte把宽字符转为UTF-8字符串接收后用MultiByteToWideChar转回wchar_t。如果直接丢去传输接收端的解码器很可能因为BOM缺失或编码不匹配而乱码。Windows乱码问题中很大一部分就来源于此跟前面说的字符集知识点其实是同一个体系。5.3 客户端与服务端联调的经验日常开发里网络层的坑更多出现在联调环节。最常见的问题之一客户端发送了数据服务端半天收不到完整包。原因通常是TCP是流式协议数据无边界需要应用层协议自己去切分包。笔试中这类题目一般不会考到但在项目经验中却很常见。我的做法是在协议设计时统一采用“包头4字节长度字段网络字节序包体”的TLV结构。若用C序列化库推荐直接引入protobuf或者flatbuffers没必要自己造轮子。6. 备考体验与实操复盘6.1 刷题之外如何真正巩固Windows知识把这套题从头到尾过完一遍之后我的体会是题目本身只是索引延伸出去的知识体系才是重点。如果你只刷题不做实验那这些知识点就是点状记忆过两周就忘如果你每遇到一个知识点都动手写一个几十行的demo去验证那这些点才会逐渐连成网。举个例子原子操作相关的题目你可以写一个多线程下的计数器程序先用普通int再用InterlockedIncrement观察两种写法在多个线程同时运行时结果的差异。如果你进一步在性能分析工具下观察锁竞争对执行时间的影响那就更好了。Windows开发的知识密度很高学习路径必须“边学边码”。实操工具方面我推荐几个Process Explorer查看进程句柄和内核对象、DebugView捕获OutputDebugString输出、WinDbg用户态和内核态调试、API Monitor监控进程的API调用。这些工具不光对笔试有帮助也是日常工作排查问题的利器。6.2 做题时的策略与常见失分点客观题的做题策略也有一些经验可谈。360这套题里的多选题少选一般不给分或给部分分错选不给分所以拿不准的选项宁可不选。题目文字里出现“错误的一项是”“不包括”“除了”这类否定词时建议把否定词圈出来这是最常见的失分点。答案模棱两可时优先选择符合Windows官方文档描述的选项而不是符合“自己经验”的选项。比如有些老程序员习惯用printf但官方环境下早就建议使用OutputDebugString或资源文件配MessageBox了。笔试选择题依据的是官方定义和行为而不是个人编码习惯。时间分配上建议先把有把握的题做完再回头啃难题。整套题客观题数量不小如果在一道指针题上耗太久后面网络或线程同步的题可能来不及做。这些都是我实际考试时踩过的坑。6.3 从笔试看岗位什么样的候选人更容易通过最后总结一下这类笔试题背后潜藏的人才标准。在我看来360这类公司要找的Windows开发工程师必须具备这样的能力能理解Windows系统机制而不只是会调用API有良好的C/C功底对内存布局、指针、结构体对齐、编码转换有肌肉记忆具备安全敏感度知道攻击者可能利用哪些系统机制做手脚能排查实际环境中的问题而不只是写“能编译”的代码。如果这套题你做得比较顺说明Windows方向的基础知识储备是合格的接下来可以针对简历上的项目做深挖准备。如果做得吃力也不要太焦虑把上面提到的知识块逐个填充起来再把每个知识点对应的实验代码写一遍面这类岗位是完全来得及的。这套题我自己刷下来的心得是Windows开发最吸引人的地方恰恰就在于它足够底层、足够有挑战性。每当你搞清楚一个系统机制的来龙去脉整个知识树就会更茂盛一点。希望这篇拆解能帮你把零散的笔试知识点串成体系祝各位春招顺利。
