故障碼trx2a17

1. 集成顯卡用什麼看電影不卡~我這機子卡的厲害~網路電視一個都看不成~包括QQ直播

我們在使用Windows XP操作系統的時候，用著用著系統就變慢了，一看「任務管理器」才發現CPU佔用達到100%。這是怎麼回事情呢?遇到病毒了，硬體有問題，還是系統設置有問題，在本文中筆者將從硬體，軟體和病毒三個方面來講解系統資源佔用率為什麼會達到100%。 l
+Rt
F@)vuS+ADf
1D#|M
經常出現CPU佔用100%的情況，主要問題可能發生在下面的某些方面: N~2a?2L@c
^d
_8qE[
zh\*MEizGk
CPU佔用率高的九種可能 he`@GN?-
v<:v~|
oJ8#_:j2:
1、防殺毒軟體造成故障 ^|e 4KZ
lU\Q}fa]
\iAE y;Fm
由於新版的KV、金山、瑞星都加入了對網頁、插件、郵件的隨機監控，無疑增大了系統負擔。處理方式:基本上沒有合理的處理方式，盡量使用最少的監控服務吧，或者，升級你的硬體配備。 '$mHpjav
o327;en
D;<H-.
2、驅動沒有經過認證，造成CPU資源佔用100% TG(9x;=MC
@9s ^IGm
GX cC7M
大量的測試版的驅動在網上泛濫，造成了難以發現的故障原因。 處理方式:尤其是顯卡驅動特別要注意，建議使用微軟認證的或由官方發布的驅動，並且嚴格核對型號、版本。 #YcYm eV+9
E15 U2:yt
1UNQ8P3
3、病毒、木馬造成 lH}0>` <O
;tvb6gyZ
LtrD=QqIS
大量的蠕蟲病毒在系統內部迅速復制，造成CPU佔用資源率據高不下。解決辦法:用可靠的殺毒軟體徹底清理系統內存和本地硬碟，並且打開系統設置軟體，察看有無異常啟動的程序。經常性更新升級殺毒軟體和防火牆，加強防毒意識，掌握正確的防殺毒知識。 |cY1mi@/
l04{TQ_ w
-@tRKex.
4、控制面板—管理工具—服務—RISING REALTIME MONITOR SERVICE點滑鼠右鍵，改為手動。
9eXX.~%'M
iRw$L 
Dn+V+8`=k}
5、開始->；運行->；msconfig->；啟動，關閉不必要的啟動項，重啟。 3pjRMc@ 3
.fMjDA A
^yDJ$Y
6、查看「svchost」進程。 { ed TK:U
W D]Sc6
e|DWJH
svchost.exe是Windows XP系統的一個核心進程。svchost.exe不單單只出現在Windows XP中，在使用NT內核的Windows系統中都會有svchost.exe的存在。一般在Windows 2000中svchost.exe進程的數目為2個，而在Windows XP中svchost.exe進程的數目就上升到了4個及4個以上。 qLF>S&_x
e+(D_~1
K CTmNs
7、查看網路連接。主要是網卡。 2hk`;a"
ZJSkPk!S
|^pP[/&' 3
8、查看網路連接 *b~`~.1F{
j%}#g2
5l<4>aI
當安裝了Windows XP的計算機做伺服器的時候，收到埠 445 上的連接請求時，它將分配內存和少量地調配 CPU資源來為這些連接提供服務。當負荷過重的時候，CPU佔用率可能過高，這是因為在工作項的數目和響應能力之間存在固有的權衡關系。你要確定合適的 MaxWorkItems 設置以提高系統響應能力。如果設置的值不正確，伺服器的響應能力可能會受到影響，或者某個用戶獨占太多系統資源。 L! Uq}2y*r
ssk_mBn
W0%"lwCmr
要解決此問題，我們可以通過修改注冊表來解決:在注冊表編輯器中依次展開[HKEY_LOCAL_ ]分支，在右側窗口中新建一個名為「maxworkitems」的DWORD值。然後雙擊該值，在打開的窗口中鍵入下列數值並保存退出: x`,Z_
o^;V6x>Vl
lWT\79br
如果計算機有512MB以上的內存，鍵入「1024」；如果計算機內存小於512 MB，鍵入「256」。 zspp ){,p
o;-u,4uL}
%0I04Twf
9、看看是不是Windows XP使用滑鼠右鍵引起CPU佔用100% 8_g+<2U

 !P
ERY^ /y9
前不久的報到說在資源管理器裡面使用滑鼠右鍵會導致CPU資源100%佔用，我們來看看是怎麼回事？ E,We>;U/}
%=rGzP
# uwE ;
徵兆: /AN] O
9R~hT>b
yw|-u4
在資源管理器裡面，當你右鍵點擊一個目錄或一個文件，你將有可能出現下面所列問題: iT? Sf
%1|%9)2g
cIQUtgM]
任何文件的拷貝操作在那個時間將有可能停止相應 <}>Lw=~0
ZQ`PY/Sz
網路連接速度將顯著性的降低 ss xLUOE
a*rc!~Tx
所有的流輸入/輸出操作例如使用Windows Media Player聽音樂將有可能是音樂失真成因: yy4os/trX
y<c80|v
當你在資源管理器裡面右鍵點擊一個文件或目錄的時候，當快捷菜單顯示的時候，CPU佔用率將增加到100%，當你關閉快捷菜單的時候才返回正常水平。 3%gpkY9
yh-(,
AtVn'dV9G
解決方法: u:@L<?/cF
TJITng$
%bl[3%`yV
方法一:關閉「為菜單和工具提示使用過渡效果」 :~-wK8zA
A >^WGF 
UA+{_H
1、點擊「開始」--「控制面板」 7ruu3V

7B"%pB]Gn
2、在「控制面板」裡面雙擊「顯示」 l+6b6{C
!I'!'>M\
3、在「顯示」屬性裡面點擊「外觀」標簽頁 RojozOk
-K s}qj
4、在「外觀」標簽頁裡面點擊「效果」 rgv|Mq3[
}m_z6
eVTgBypW
5、在「效果」對話框裡面，清除「為菜單和工具提示使用過渡效果」前面的復選框接著點擊兩次「確定」按鈕。 oJJ*0kNT
5ZhY3bl0
YChzF6i
方法二:在使用滑鼠右鍵點擊文件或目錄的時候先使用滑鼠左鍵選擇你的目標文件或目錄。然後再使用滑鼠右鍵彈出快捷菜單。 0U^/E
L6 Kb 
;}
LtcC
CPU佔用100%解決辦法 7q,lD(p
tOh*#q&{
m{vt.z|bqF
一般情況下CPU佔了100%的話我們的電腦總會慢下來，而很多時候我們是可以通過做一點點的改動就可以解決，而不必問那些大蝦了。 `(Cw
h8>
I\O\d
E=NL8vv
當機器慢下來的時候，首先我們想到的當然是任務管理器了，看看到底是哪個程序佔了較搞的比例，如果是某個大程序那還可以原諒，在關閉該程序後只要CPU正常了那就沒問題；如果不是，那你就要看看是什幺程序了，當你查不出這個進程是什幺的時候就去google或者搜。有時只結束是沒用的，在xp下我們可以結合msconfig里的啟動項，把一些不用的項給關掉。在2000下可以去下個winpatrol來用。 Nt UH:>
!&RZdfq@
xIYH)mM8>
一些常用的軟體，比如瀏覽器佔用了很搞的CPU，那幺就要升級該軟體或者乾脆用別的同類軟體代替，有時軟體和系統會有點不兼容，當然我們可以試下xp系統下給我們的那個兼容項，右鍵點該.exe文件選兼容性。 1ooS.mm
4M8lY!6b
,torrfLU
svchost.exe有時是比較頭痛的，當你看到你的某個svchost.exe佔用很大CPU時你可以去下個aports或者fport來檢查其對應的程序路徑，也就是什幺東西在掉用這個svchost.exe，如果不是c:Windowssystem32(xp)或c:winntsystem32(2000)下的，那就可疑。升級殺毒軟體殺毒吧。 ]p^ewF f
vs: !p=y{
u}amM
KDyc
右擊文件導致100%的CPU佔用我們也會遇到，有時點右鍵停頓可能就是這個問題了。官方的解釋:先點左鍵選中，再右鍵(不是很理解)。非官方:通過在桌面點右鍵-屬性-外觀-效果，取消」為菜單和工具提示使用下列過度效果(U)「來解決。還有某些殺毒軟體對文件的監控也會有所影響，可以關閉殺毒軟體的文件監控；還有就是對網頁，插件，郵件的監控也是同樣的道理。 B6{=Y.kt.
&-CP!*+h)
Ap?_h
一些驅動程序有時也可能出現這樣的現象，最好是選擇微軟認證的或者是官方發布的驅動來裝，有時可以適當的升級驅動，不過記得最新的不是最好的。 hb:L?'7",7
_ze['CI
rkM"h3 8X
CPU降溫軟體，由於軟體在運行時會利用所以的CPU空閑時間來進行降溫，但Windows不能分辨普通的CPU佔用和降溫軟體的降溫指令之間的區別，因此CPU始終顯示100%，這個就不必擔心了，不影響正常的系統運行。 knzSX
DWxYZlsk
MypvL!3|e
在處理較大的word文件時由於word的拼寫和語法檢查會使得CPU累，只要打開word的工具-選項-拼寫和語法把」檢查拼寫和檢查語法「勾去掉。 ?:O,mv>
9/,:^0YZ
F5wcHm ;
單擊avi視頻文件後CPU佔用率高是因為系統要先掃描該文件，並檢查文件所有部分，並建立索引；解決辦法:右擊保存視頻文件的文件夾-屬性-常規-高級，去掉為了快速搜索，允許索引服務編制該文件夾的索引的勾。 E)dF7
s,A hGJ
B]+{0'Z
CPU佔用100%案例分析 0JSI8 3
_ `dp `2
v$}tu % V
1、dllhost進程造成CPU使用率佔用100% N|~JkE{I
YuXUhxjZ)
).G,-r
mX
特徵:伺服器正常CPU消耗應該在75%以下，而且CPU消耗應該是上下起伏的，出現這種問題的伺服器，CPU會突然一直處100%的水平，而且不會下降。查看任務管理器，可以發現是DLLHOST.EXE消耗了所有的CPU空閑時間，管理員在這種情況下，只好重新啟動IIS服務，奇怪的是，重新啟動IIS服務後一切正常，但可能過了一段時間後，問題又再次出現了。 CFTZchyk
M*pWD+h\
.[1.}Z'YP
直接原因: tf #JBR
. 71V3^:
;(EpI$[dG
有一個或多個ACCESS資料庫在多次讀寫過程中損壞，微軟的MDAC系統在寫入這個損壞的ACCESS文件時，ASP線程處於BLOCK狀態，結果其它線程只能等待，IIS被死鎖了，全部的CPU時間都消耗在DLLHOST中。 j%3VBe&4V
93w3"uZ)
Hmd;U9
解決辦法: ,5WRO9
k729`9V]
@AWaL ~s:
安裝「一流信息監控攔截系統」，使用其中的「首席文件檢查官IIS健康檢查官」軟體， _E3O%-,n
S HfCob
B:mzzGt*
啟用」查找死鎖模塊」，設置: \?;L/fLY'
CFiyPzZ
mc
]Iw9&S
--wblock=yes <qB_FfI
P>R@;&w
監控的目錄，請指定您的主機的文件所在目錄: <} /s D
+5 ]vL02
--wblockdir=d: est {],Co'o
[zWxAo8Z
S08`v7Y<
監控生成的日誌的文件保存位置在安裝目錄的log目錄中，文件名為:logblock.htm A(a 1ad
PUWO\ I#
c'Z(k%F
停止IIS，再啟動「首席文件檢查官IIS健康檢查官」，再啟動IIS，「首席文件檢查官IIS健康檢查官」會在logblock.htm中記錄下最後寫入的ACCESS文件的。 K|w~)VQs
QL7#L,
r;Kvg!
過了一段時間後，當問題出來時，例如CPU會再次一直處100%的水平，可以停止IIS，檢查logblock.htm所記錄的最後的十個文件，注意，最有問題的往往是計數器類的ACCESS文件，例如:」**COUNT.MDB」，」**COUNT.ASP」，可以先把最後十個文件或有所懷疑的文件刪除到回收站中，再啟動IIS，看看問題是否再次出現。我們相信，經過仔細的查找後，您肯定可以找到這個讓您操心了一段時間的文件的。 M@`tyr/=
]eU WZ 3
=C:$l;C
找到這個文件後，可以刪除它，或下載下來，用ACCESS2000修復它，問題就解決了。 ,I{v[XeO
UCrTwOp
9zh_@,
T
2、svchost.exe造成CPU使用率佔用100% IWm!taY
YA4UvOjI;~
#3CmC$"b
在win.ini文件中，在[Windows]下面，「run=」和「load=」是可能載入「木馬」程序的途徑，必須仔細留心它們。一般情況下，它們的等號後面什幺都沒有，如果發現後面跟有路徑與文件名不是你熟悉的啟動文件，你的計算機就可能中上「木馬」了。當然你也得看清楚，因為好多「木馬」，如「AOL Trojan木馬」，它把自身偽裝成command.exe文件，如果不注意可能不會發現它不是真正的系統啟動文件。 G#=gm(2Qt
Q)lD
t5,
Qrz (SI%kA
在system.ini文件中，在[BOOT]下面有個「shell=文件名」。正確的文件名應該是「explorer.exe」，如果不是「explorer.exe」，而是「shell= explorer.exe 程序名」，那幺後面跟著的那個程序就是「木馬」程序，就是說你已經中「木馬」了。 mw?N-Ew
3)boiZ6

cy^0g^?tD~
在注冊表中的情況最復雜，通過regedit命令打開注冊表編輯器，在點擊至:「HKEY-LOCAL-」目錄下，查看鍵值中有沒有自己不熟悉的自動啟動文件，擴展名為EXE，這里切記:有的「木馬」程序生成的文件很像系統自身文件，想通過偽裝矇混過關，如「Acid Battery v1.0木馬」，它將注冊表「HKEY-LOCAL-」下的Explorer 鍵值改為Explorer=「C:Windowsexpiorer.exe」，「木馬」程序與真正的Explorer之間只有「i」與「l」的差別。當然在注冊表中還有很多地方都可以隱藏「木馬」程序，如:「HKEY-CURRENT-」、「HKEY-USERS****」的目錄下都有可能，最好的辦法就是在「HKEY-LOCAL-」下找到「木馬該病毒也稱為「Code Red II(紅色代碼2)」病毒，與早先在西方英文系統下流行「紅色代碼」病毒有點相反，在國際上被稱為VirtualRoot(虛擬目錄)病毒。該蠕蟲病毒利用Microsoft已知的溢出漏洞，通過80埠來傳播到其它的Web頁伺服器上。受感染的機器可由黑客們通過Http Get的請求運行scripts/root.exe來獲得對受感染機器的完全控制權。 }y+us\4:s
Q }K]sr
>D >:2a_
當感染一台伺服器成功了以後，如果受感染的機器是中文的系統後，該程序會休眠2天，別的機器休眠1天。當休眠的時間到了以後，該蠕蟲程序會使得機器重新啟動。該蠕蟲也會檢查機器的月份是否是10月或者年份是否是2002年，如果是，受感染的伺服器也會重新啟動。當Windows NT系統啟動時，NT系統會自動搜索C盤根目錄下的文件explorer.exe，受該網路蠕蟲程序感染的伺服器上的文件explorer.exe也就是該網路蠕蟲程序本身。該文件的大小是8192位元組，VirtualRoot網路蠕蟲程序就是通過該程序來執行的。同時，VirtualRoot網路蠕蟲程序還將cmd.exe的文件從Windows NT的system目錄拷貝到別的目錄，給黑客的入侵敞開了大門。它還會修改系統的注冊表項目，通過該注冊表項目的修改，該蠕蟲程序可以建立虛擬的目錄C或者D，病毒名由此而來。值得一提的是，該網路蠕蟲程序除了文件explorer.exe外，其餘的操作不是基於文件的，而是直接在內存中來進行感染、傳播的，這就給捕捉帶來了較大難度。 >5k~ bzyV
w"`k2N5
//1?.J6eO
」程序的文件名，再在整個注冊表中搜索即可。 ydQm/ZYQ
#>SSBg }v
,? xO?P
我們先看看微軟是怎樣描述svchost.exe的。在微軟知識庫314056中對svchost.exe有如下描述:svchost.exe 是從動態鏈接庫 (DLL) 中運行的服務的通用主機進程名稱。 YvRFxSi
9_`mL+
ZWjQgVc+]
其實svchost.exe是Windows XP系統的一個核心進程。svchost.exe不單單只出現在Windows XP中，在使用NT內核的Windows系統中都會有svchost.exe的存在。一般在Windows 2000中svchost.exe進程的數目為2個，而在Windows XP中svchost.exe進程的數目就上升到了4個及4個以上。所以看到系統的進程列表中有幾個svchost.exe不用那幺擔心。 Z@qfg/\:
S4hgvi6!3
R" #O,N%j
svchost.exe到底是做什幺用的呢? rU]YW.pC(^
<YFni| :
>+ ]?F(
首先我們要了解一點那就是Windows系統的中的進程分為:獨立進程和共享進程這兩種。由於Windows系統中的服務越來越多，為了節約有限的系統資源微軟把很多的系統服務做成了共享模式。那svchost.exe在這中間是擔任怎樣一個角色呢? Q/Z Il
6 w T&;N
AC My f
svchost.exe的工作就是作為這些服務的宿主，即由svchost.exe來啟動這些服務。svchost.exe只是負責為這些服務提供啟動的條件，其自身並不能實現任何服務的功能，也不能為用戶提供任何服務。svchost.exe通過為這些系統服務調用動態鏈接庫(DLL)的方式來啟動系統服務。 @owIz
/ aY;a&k%
'g4p<)
svchost.exe是病毒這種說法是任何產生的呢? )9$4Wh;
^,ecVi F
8:y{l
6
因為svchost.exe可以作為服務的宿主來啟動服務，所以病毒、木馬的編寫者也挖空心思的要利用svchost.exe的這個特性來迷惑用戶達到入侵、破壞計算機的目的。 e<4wkris
g( q;+b
XqZKDM
如何才能辨別哪些是正常的svchost.exe進程，而哪些是病毒進程呢? n j7gePxU
7F`CJM
!} i{
svchost.exe的鍵值是在「HKEY_LOCAL_ NTCurrentVersionSvchost」，如圖1所示。圖1中每個鍵值表示一個獨立的svchost.exe組。 W_6:B\WC
wM1d_2
=-~Kt{
微軟還為我們提供了一種察看系統正在運行在svchost.exe列表中的服務的方法。以Windows XP為例:在「運行」中輸入:cmd，然後在命令行模式中輸入:tasklist /svc。系統列出如圖2所示的服務列表。圖2中紅框包圍起來的區域就是svchost.exe啟動的服務列表。如果使用的是Windows 2000系統則把前面的「tasklist /svc」命令替換為:「tlist -s」即可。如果你懷疑計算機有可能被病毒感染，svchost.exe的服務出現異常的話通過搜索svchost.exe文件就可以發現異常情況。一般只會找到一個在:「C:WindowsSystem32」目錄下的svchost.exe程序。如果你在其它目錄下發現svchost.exe程序的話，那很可能就是中毒了。 v:]R1rH 6
0 {8^wS
Nzb7uK|Z
還有一種確認svchost.exe是否中毒的方法是在任務管理器中察看進程的執行路徑。但是由於在Windows系統自帶的任務管理器不能察看進程路徑，所以要使用第三方的進程察看工具。  $#2Ja
vd&y_V1 A
_Qc%-?`t},
上面簡單的介紹了svchost.exe進程的相關情況。總而言之，svchost.exe是一個系統的核心進程，並不是病毒進程。但由於svchost.exe進程的特殊性，所以病毒也會千方百計的入侵svchost.exe。通過察看svchost.exe進程的執行路徑可以確認是否中毒。 Z[MOokJm 
8`f[$H Gl
E!bYHn:y
3、Services.exe造成CPU使用率佔用100% D %UL>
wxxMOoD=
P1jrO&V'
症狀 6jEY)
svf\ cD)
KeH Sb!h;
在基於 Windows 2000 的計算機上，Services.exe 中的 CPU 使用率可能間歇性地達到100 %，並且計算機可能停止響應(掛起)。出現此問題時，連接到該計算機(如果它是文件伺服器或域控制器)的用戶會被斷開連接。您可能還需要重新啟動計算機。如果 Esent.dll 錯誤地處理將文件刷新到磁碟的方式，則會出現此症狀。 B>[qWX:
+ #%K-,
Dp0{XEMb~
解決方案 %-aOK
FX<,f
|bTjM%kq(
Service Pack 信息 hF ^/_p

5.me^yx6$
`~Mxm'n1
要解決此問題，請獲取最新的 Microsoft Windows 2000 Service Pack。有關其它信息，請單擊下面的文章編號，以查看 Microsoft 知識庫中相應的文章: hNas]
srjT1Ng
AA#Zh;5Q
260910 如何獲取最新的 Windows 2000 Service Pack ?A9Gvwr
j pU `Z
tUg6{,/~3U
修復程序信息 LpOww%
2I{&43$Q
[RP"A:V
Microsoft 提供了受支持的修補程序，但該程序只是為了解決本文所介紹的問題。只有計算機遇到本文提到的特定問題時才可應用此修補程序。此修補程序可能還會接受其它一些測試。因此，如果這個問題沒有對您造成嚴重的影響，Microsoft 建議您等待包含此修補程序的下一個 Windows 2000 Service Pack。 'xLjW0bx
tK_ L
p l{iR-L"s
要立即解決此問題，請與「Microsoft 產品支持服務」聯系，以獲取此修補程序。有關「Microsoft 產品支持服務」電話號碼和支持費用信息的完整列表，請訪問 Microsoft Web 站點: ?z0[~,
;X\<q c<
~ tJ6e\
注意 :特殊情況下，如果 Microsoft 支持專業人員確定某個特定的更新程序能夠解決您的問題，可免收通常情況下收取的電話支持服務費用。對於特定更新程序無法解決的其它支持問題和事項，將正常收取支持費用。 MU/0*W'a$
&;XE`ZLJ
( D&kq DW
下表列出了此修補程序的全球版本的文件屬性(或更新的屬性)。這些文件的日期和時間按協調通用時間 (UTC) 列出。查看文件信息時，它將轉換為本地時間。要了解 UTC 與本地時間之間的時差，請使用「控制面板」中的「日期和時間」工具中的 時區 選項卡。 ^^.&#Uif`
)9!73#4
4 2wl=4[
狀態 HbXH*1/E
g]FaM1Ph
\/`
1u=
Microsoft 已經確認這是在本文開頭列出的 Microsoft 產品中存在的問題。此問題最初是在 Microsoft Windows 2000 Service Pack 4 中更正的。 {y6 +(bN
3h ))pq
?qbO O+Nk
4、正常軟體造成CPU使用率佔用100% " .X+ ~Uc
h>SI74Hx$
GS!<)*
首先，如果是從開機後就發生上述情況直到關機。那幺就有可能是由某個隨系統同時登陸的軟體造成的。可以通過運行輸入「msconfig」打開「系統實用配置工具」，進入「啟動」選項卡。接著，依次取消可疑選項前面的對鉤，然後重新啟動電腦。反復測試直到找到造成故障的軟體。或者可以通過一些優化軟體如「優化大師」達到上述目的。另:如果鍵盤內按鍵卡住也可能造成開機就出現上述問題。 #dd)UBAp<
>jf.[U}|
)#|wB'5w0
如果是使用電腦途中出項這類問題，可以調出任務管理器(WINXP CTRL+ALT+DEL WIN2000 CTRL+SHIFT「ESC)，進入」進程「選項卡，看」CPU「欄，從裡面找到佔用資源較高的程序(其中SYSTEM IDLE PROCESS是屬於正常，它的值一般都很高，它的作用是告訴當前你可用的CPU資源是多少，所以它的值越高越好)通過搜索功能找到這個進程屬於哪個軟體。然後，可以通過升級、關閉、卸載這個軟體或者乾脆找個同類軟體替換，問題即可得到解決。 Yjen@pK
L)"]y$JdA
 ppQx*fA
5、病毒、木馬、間諜軟體造成CPU使用率佔用100% vmC
@:`.;8

TnZ ~}(
ey
%PK
出現CPU佔用率100% 的故障經常是因為病毒木馬造成的，比如震盪波病毒。應該首先更新病毒庫，對電腦進行全機掃描 。接著，在使用反間諜軟體Ad—Aware，檢查是否存在間諜軟體。論壇上有不少朋友都遇到過svchost.exe佔用CPU100%，這個往往是中毒的表現。 hyFPs:bBh
w& }wOg 8
!,[ a^DRT(
svchost.exe Windows中的系統服務是以動態鏈接庫(DLL)的形式實現的，其中一些會把可執行程序指向svchost.exe，由它調用相應服務的動態鏈接庫並加上相應參數來啟動服務。正是因為它的特殊性和重要性，使它更容易成為了一些病毒木馬的宿主。 o}X\Z-gS
C qq `E

hwKR,-N
6、explorer.exe進程造成CPU使用率佔用100% oZUu[Aq"xq
9:
c*Gw 7
dv@*4}H
在system.ini文件中，在[BOOT]下面有個「shell=文件名」。正確的文件名應該是「explorer.exe」，如果不是「explorer.exe」，而是「shell= explorer.exe 程序名」，那幺後面跟著的那個程序就是「木馬」程序，就是說你已經中「木馬」了。 nlAO\Tjwo
DBNhdR?7@d
5MRC}]8M
在注冊表中的情況最復雜，通過regedit命令打開注冊表編輯器，在點擊至:「HKEY-LOCAL-」目錄下，查看鍵值中有沒有自己不熟悉的自動啟動文件，擴展名為EXE，這里切記:有的「木馬」程序生成的文件很像系統自身文件，想通過偽裝矇混過關，如「Acid Battery v1.0木馬」，它將注冊表「HKEY-LOCAL-」下的 Wq\B) ,Mb
0G)BS
e
I=zL,7[
Explorer 鍵值改為Explorer=「C:Windowsexpiorer.exe」，「木馬」程序與真正的Explorer之間只有「i」與「l」的差別。當然在注冊表中還有很多地方都可以隱藏「木馬」程序，如:「HKEY-CURRENT-」、「HKEY-USERS****」的目錄下都有可能，最好的辦法就是在「HKEY-LOCAL-」下找到「木馬」程序的文件名，再在整個注冊表中搜索即可。 s<j])k4
kQ+r&*e\
Ryvo7B!Q
7、超線程導致CPU使用率佔用100% 8wS:hd
;nBxoDp
o'gJWi|(JT
這類故障的共同原因就是都使用了具有超線程功能的P4 CPU。我查找了一些資料都沒有明確的原因解釋。據一些網友總結超線程似乎和天網防火牆有沖突，可以通過卸載天網並安裝其它防火牆解決，也可以通過在BIOS中關閉超線程功能解決。 g4C`H
VWMFR %Y
V76?fk(
8、AVI視頻文件造成CPU使用率佔用100% T, <nZ@-
o0d7} Q,
"U NVg~2
在Windows XP中，單擊一個較大的AVI視頻文件後，可能會出現系統假死現象，並且造成exploere.exe進程的使用率100%，這是因為系統要先掃

2. MySQL 5.7中新增sys schema有什麼好處

性能優化利器:剖析MySQL 5.7新特徵 sys schema

導讀：很多團隊在評估合適的時機切換到 MySQL 5.7，本文是在高可用架構群的分享，介紹 MySQL 5.7 新的性能分析利器。

李春，現任科技 MySQL 負責人，高級 MySQL 資料庫專家，從事 MySQL 開發和運維工作 8 年。在擔任 MySQL 資料庫 leader 期間，主要負責應用架構的優化和部署，實現了阿里巴巴 3 億 產品 從 Oracle 小型機到 64 台 MySQL 的平滑遷移。專注於研究 MySQL 復制、高可用、分布式和運維自動化相關領域。在大規模、分布式 MySQL 集群管理、調優、快速定位和解決問題方面有豐富經驗。管理超過 1400 台 MySQL 伺服器，近 3000 個實例。完成 MySQL 自動裝機系統、MySQL 標准化文檔和操作手冊、MySQL 自動規范性檢查系統、MySQL 自動信息採集系統等標准化文檔和自動化運維工具。

sys schema 由來

Performance schema 引入

Oracle 早就有了 v$ 等一系列方便診斷資料庫性能的工具，MySQL DBA 只有羨慕嫉妒恨的份，但是 5.7 引入的 sys schema 緩解了這個問題，讓我們可以通過 sys schema 一窺 MySQL 性能損耗，診斷 MySQL 的各種問題。

說到診斷 MySQL 性能問題，不得不提在 MySQL 5.5 引入的 performance_schema，最開始引入時，MySQL 的 performance_schema 性能消耗巨大，隨著版本的更新和代碼優化，5.7 的 performance_schema 對 MySQL 伺服器額外的消耗越來越少，我們可以放心的打開 performance_shema 來收集 MySQL 資料庫的性能損耗。Tarique Saleem 同學測試了一下 sys schema 對 CPU 和 IO的額外消耗，基本在 1% - 3% 之間，有興趣的同學可以參考他的這篇 blog：

（CPU Bound, Sysbench Read Only Mode）

performance_schema 不僅由於他的性能消耗大著名，還由於其復雜難用而臭名昭著。5.7 上的 performance schema 已經有 87 張表了，每個表都是各種統計信息的羅列；另外，他的這些表和 information_schema 中的部分表也纏夾不清，讓大家用得很不習慣。

sys schema VS performance schema VS information schema

現在 MySQL 在 5.7 又新增了sys schema，它和 performance_schema 和 information schema 到底是什麼關系？

Information_schema 定位基本是 MySQL 元數據信息，比如：TABLES 記錄了 MySQL 有哪些表，COLUMNS 記錄了各個表有哪些列 。

performance_schema 記錄了 MySQL 實時底層性能消耗情況，比如：events_waits_current 記錄了 MySQL 各個線程當前在等待的 event。

雖然他們之間的這個定位區別並沒有那麼明顯：比如，Information_schema 的 innodb_locks 就記錄了 innodb 當前鎖的信息，它並不是 MySQL 的元數據信息。sys schema 最開始是 MarkLeith 同學為了方便讀取和診斷 MySQL 性能引入到 MySQL 的。所以 sys schema 定位應該是最清晰的：它包含一系列對象，這些對象能夠輔助 DBA 和開發人員了解 performance schema 和 information_schema 採集的數據。

sys schema 包含了什麼？

sys schema 包含一些對象，這些對象主要用於調優和故障分析。包括：

將 performance schema 和 information schema 中的數據用更容易理解的方式來總結歸納出來的「視圖」。

提供 performance schema 和 information schema 配置或者生成分析報告類似操作的「存儲過程」

sys schema 本身不採集和存儲什麼信息，它只是為程序或者用戶提供一個更加方便的診斷系統性能和排除故障的「介面」。也就是說，查詢 performance schema 和 information schema 配置和提供格式化服務的「存儲函數」。

避免用戶在 information schema 和 performance schema 中寫各種復雜的查詢來獲得到底誰鎖了誰，每個線程消耗的內存是多少 ( 視圖 memory_by_thread_by_current_bytes )，每個 SQL 執行了多少次，大致的執行時間是多少（ 視圖 statements_with_runtimes_in_95th_percentile ）等，這些 sys schema 都直接幫你寫好，你只需要直接查詢就好了。

編寫了一些現成的存儲過程，方便你：直接使用 diagnostics() 存儲過程創建用於診斷當前伺服器狀態的報告；使用 ps_trace_thread() 存儲過程創建對應線程的圖形化（ .dot類型 ）性能數據。

編寫了一些現成的存儲函數，方便你：直接使用 ps_thread_account() 存儲函數獲得發起這個線程的用戶，使用 ps_thread_trx_info() 來獲得某線程當前事務或者歷史執行過的語句（ JSON 格式返回 ）。

當然，你也可以在 sys schema 下增加自己用於診斷 MySQL 性能的「視圖」、「存儲過程」和「存儲函數」。

sys schema 舉例

怎麼利用 sys schema 來定位問題和診斷資料庫性能？這里簡單舉一個 innodb 行鎖的例子來說明。

模擬行鎖

拿一個實際的場景來說 sys schema 能夠輔助我們分析當前資料庫上哪個 session 被鎖住了，並且提供「清理」鎖的語句。我們模擬一個表的某一行被鎖住的情況，假設表創建語句如下：

CREATE TABLE `test2` (

`id` int(11) NOT NULL,

`name` varchar(16) DEFAULT NULL,

`age` int(11) DEFAULT NULL,

`sex` int(11) DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1

有一條數據如下：

mysql > select * from test2;

+----+---------+------+------+

| id | name | age | sex |

+----+---------+------+------+

| 2 | pickup1 | 1 | 1 |

+----+---------+------+------+

我們分別在 session 1 和 session 2 上同時操作這條數據，這樣的話必然對同一行記錄相互有鎖死的情況，然後我們通過 session 3 來查看 sys schema 裡面的 innodb_lock_waits，確定到底是誰鎖了誰，怎麼解鎖？操作步驟如下：

通過 sys.innodb_lock_waits 查看 innodb 鎖表情況

對應的在 session 3上查看到的記錄：

mysql > select * from sys.innodb_lock_waitsG

*************************** 1. row ***************************

wait_started: 2016-05-04 01:04:38

wait_age: 00:00:02

wait_age_secs: 2

locked_table: `test`.`test2`

locked_index: PRIMARY

locked_type: RECORD

waiting_trx_id: 5382

waiting_trx_started: 2016-05-04 00:24:21

waiting_trx_age: 00:40:19

waiting_trx_rows_locked: 4

waiting_trx_rows_modified: 0

waiting_pid: 3

waiting_query: update test2 set name='pickup3' where id=2

waiting_lock_id: 5382:31:3:3

waiting_lock_mode: X

blocking_trx_id: 5381

blocking_pid: 2

blocking_query: NULL

blocking_lock_id: 5381:31:3:3

blocking_lock_mode: X

blocking_trx_started: 2016-05-04 00:23:49

blocking_trx_age: 00:40:51

blocking_trx_rows_locked: 1

blocking_trx_rows_modified: 1

sql_kill_blocking_query: KILL QUERY 2

sql_kill_blocking_connection: KILL 2

這里我們可以看到 3 號線程（ waiting_pid: 3 ）在等待 2 號線程（ blocking_pid: 2 ）的 X 鎖（ blocking_lock_mode: X ），如果需要解鎖，需要殺掉 2 號線程（ sql_kill_blocking_connection: KILL 2 ）。

innodb_lock_waits 本質

其實 sys schema 的 innodb_lock_waits 只是 information schema 的視圖而已。

CREATE ALGORITHM = TEMPTABLE DEFINER = `mysql.sys`@`localhost` SQL SECURITY INVOKER VIEW `innodb_lock_waits` AS

SELECT

`r`.`trx_wait_started` AS `wait_started`,

TIMEDIFF(NOW(),

`r`.`trx_wait_started`) AS `wait_age`,

TIMESTAMPDIFF(

SECOND,

`r`.`trx_wait_started`,

NOW()) AS `wait_age_secs`,

`rl`.`lock_table` AS `locked_table`,

`rl`.`lock_index` AS `locked_index`,

`rl`.`lock_type` AS `locked_type`,

`r`.`trx_id` AS `waiting_trx_id`,

`r`.`trx_started` AS `waiting_trx_started`,

TIMEDIFF(NOW(),

`r`.`trx_started`) AS `waiting_trx_age`,

`r`.`trx_rows_locked` AS `waiting_trx_rows_locked`,

`r`.`trx_rows_modified` AS `waiting_trx_rows_modified`,

`r`.`trx_mysql_thread_id` AS `waiting_pid`,

`sys`.`format_statement`(`r`.`trx_query`) AS `waiting_query`,

`rl`.`lock_id` AS `waiting_lock_id`,

`rl`.`lock_mode` AS `waiting_lock_mode`,

`b`.`trx_id` AS `blocking_trx_id`,

`b`.`trx_mysql_thread_id` AS `blocking_pid`,

`sys`.`format_statement`(`b`.`trx_query`) AS `blocking_query`,

`bl`.`lock_id` AS `blocking_lock_id`,

`bl`.`lock_mode` AS `blocking_lock_mode`,

`b`.`trx_started` AS `blocking_trx_started`,

TIMEDIFF(NOW(),

`b`.`trx_started`) AS `blocking_trx_age`,

`b`.`trx_rows_locked` AS `blocking_trx_rows_locked`,

`b`.`trx_rows_modified` AS `blocking_trx_rows_modified`,

CONCAT(

'KILL QUERY ',

`b`.`trx_mysql_thread_id`

) AS `sql_kill_blocking_query`,

CONCAT('KILL ',

`b`.`trx_mysql_thread_id`) AS `sql_kill_blocking_connection`

FROM

(

(

(

(

`information_schema`.`innodb_lock_waits` `w`

JOIN

`information_schema`.`innodb_trx` `b` ON((`b`.`trx_id` = `w`.`blocking_trx_id`))

)

JOIN

`information_schema`.`innodb_trx` `r` ON(

(`r`.`trx_id` = `w`.`requesting_trx_id`)

)

)

JOIN

`information_schema`.`innodb_locks` `bl` ON(

(

`bl`.`lock_id` = `w`.`blocking_lock_id`

)

)

)

JOIN

`information_schema`.`innodb_locks` `rl` ON(

(

`rl`.`lock_id` = `w`.`requested_lock_id`

)

)

)

ORDER BY

`r`.`trx_wait_started`

innodb_lock_waits和x$innodb_lock_waits區別

有心的同學可能會注意到，sys schema 裡面有 innodb_lock_waits 和 x$innodb_lock_waits。其實 sys schema 的這些視圖大部分都成對出現，其中一個的名字除了 x$ 前綴以外跟另外一個是一模一樣的。例如，host_summmary_by_file_io 視圖分析匯總的是根據主機匯總的文件 IO 情況，並將延遲從皮秒（ picoseconds ）轉換成更加易讀值（ 帶單位 ）顯示出來：

mysql> SELECT * FROM host_summary_by_file_io;

+------------+-------+------------+

| host | ios | io_latency |

+------------+-------+------------+

| localhost | 67570 | 5.38 s |

| background | 3468 | 4.18 s |

+------------+-------+------------+

而 x$host_summary_by_file_io 視圖分析匯總的是同樣的數據，但是顯示的是未格式化過的皮秒（ picosecond ）延遲值

mysql> SELECT * FROM x$host_summary_by_file_io;

+------------+-------+---------------+

| host | ios | io_latency |

+------------+-------+---------------+

| localhost | 67574 | 5380678125144 |

| background | 3474 | 4758696829416 |

+------------+-------+---------------+

沒有 x$ 前綴的視圖是為了提供更加友好，對人更加易讀的輸出格式。帶 x$ 前綴的視圖顯示了數據原始格式，它方便其他工具基於這些數據進行自己的處理。需要了解非 x$ 和 x$ 視圖的不同點的進一步信息。

Q&A

提問：sys schema 只是在 performance_schema 和 information_schema 之上創建視圖和存儲過程？

李春：對，sys schema 主要針對的其實是 iperformance schema，有部分 information schema 的表也會整理到 sys schema 中統一展現。

提問：運行 KILL 2 殺掉 2 線程？blocking_lock_mode: X 的 X 什麼意思？

李春：blocking_lock_mode 的 X 是指 X 鎖，exclusive 鎖，排它鎖，跟它對應的是 S 鎖，共享鎖。kill 2 是殺掉 2 號線程，這樣可以將鎖釋放，讓被鎖的這個線程正常執行下去。

提問：可以放心的打開 performance_schema，為何不使用 performance_schema 再造一個 sys schema？

李春：performance schema 是 MySQL 採集資料庫性能的存儲空間。sys schema 其實只是對 performance schema 多個表 join 和整合。兩者的定位有所不同，如果直接放在 performance schema 中，分不清哪些是基表，哪些是視圖，會比較混淆。

提問：pt-query-digest 這些工具的有開始使用 sys schema 嗎？

李春：沒有，pt-query-digest 主要用於分析慢查和 tcpmp 的結果，跟 sys schema 的定位有部分重疊的地方，sys schema 會分析得更細，更內核，更偏底層一些，pt-query-digest 主要還是從慢查和 tcpmp 中抽取 SQL 來格式化展現。

提問：阿里這么多資料庫實例，使用什麼運維工具？分布式事務又是怎麼解決的呢？

李春：阿里內部有非常多的運維工具，dbfree，idb 等，用於資料庫資源池管理，資料庫脫敏，開發測試庫同步，資料庫訂正，表結構變更等。分布式事務主要通過業務上的修改去屏蔽掉，比如：電影買票並不是你選了座位和付款就必須在一個事務裡面，搶票，選座，付款分別是自己的子事務，系統耦合性比較弱，相互通知解決問題。

提問：Oracle 有 v$，MySQL 有 x$ ？兩個 $ 是完成相似功能的嗎？

李春：MySQL 的 x$ 可以說是仿照 Oracle 的 v$ 來做的，但是目前離 Oracle 的那麼強大的資料庫診斷功能還有一些距離。

提問：資料庫脫敏能否簡單介紹下實現方式？

李春：開發測試人員無法訪問線上資料庫，需要通過一個專門的 idb 來訪問，而 idb 系統每個欄位都有密級定義，滿足許可權的才能被訪問；這個系統頁控制了用戶是否可以訪問某個表，可以訪問數據表的行數，只有主管同意了，用戶才能訪問某個表的數據，並且加密數據是以*顯示的。

3. 某一trx故障，都會導致哪些不良結果

（
主要表現：
觀察處理：
關跳頻時，
切換：向外切換時，下行質差緊急切換多；切入城功率較低；接通率低；
（
主要表現：
ICM統計上：出現有兩極分化的上行干擾，即在測試報告中，5級，查告警有2個載波有故障，用
個別載波的接收靈敏度低：MOTS啟用，可輔助發現問題，即某些3）、
忙時
個別TRU有問題，一佔用就導致閉塞，指配成功率低，若用
另外，有些載波故障在佔用後不會出現閉塞，但在路測時，信號較強的情況下，統計事件中有指配不成功，QD與UNUSED,關跳頻後無異常。200站故障：TRX後也無改善。大部分為 經常在路測中發現，小區開跳頻後強信號質差，關跳頻後測試結果正常。
④、SU掉話較嚴重；其靈敏度較BSRXMIN可緩和掉話情況）
①、TRX、
②、傳輸設備RXAPI）。此類故障經常導致倒站，或信道完好率偏低，嚴重擁塞等。2000站傳輸串聯。在開站或載調整時，半永久性連接定義出錯，經常有載波不能正常工作，擁塞率高。CELL連接錯誤，結果將
⑤、UNUSED。SD或TS經常有LOAD後則恢復正常。有時閉解後故障消除，但掉話急劇增多，特別是
2、
（TRH DEV編號，拆小區
（
（HSN的小區存在，若如此，試改TRH的問題。拆小區
（LOATING UPDATA（位置更新），導致RLCRP觀察）。一般對小區OK。SDCCH極忙而TCH接通率極低的情況，尤其TRXC版本後恢復正常。E頻段（擴展頻段）後，個別小區LOAD後無效，恢復用 參數設置問題CGI時，在MSC漏定，或同一CGI重疊。會導致該小區掉話率極高（
（BSIC的小區相隔太近，將導致其中一小區（或兩小區同時）切入成功率很低，話音接通率及信令接通率，掉話也可能局部增多。BCCH同4）、分層不當或5）、某小區的兩個鄰區有相同的6）、B小區有切換，而
（MSRXSUFF設置不當，與
（
（
（BSTXPWR設置與其他小區思路不一致，致使切入、切出不平衡。CRO設置太高，可能導致成片區域用戶多次打不通電話，或投訴信號時強時弱。MBCCHNO，切換異常。
整體性成功率低：檢查MSC地址、58源分析表、交換MSC、 天線的故障
①、QU掉話多，切入成功率低。D型，與上述情況類似，可能發射天線正常而接收天線掉錯。C型或QD、SUD掉話都較多；上下行質差切換比例多； 同理，也有三個小區天線連環交叉的問題。
單小區天線的方向角不一致，先區分是CDU-D型，其跡象略有區別：SU掉話比例較大；切入成功率與話音接通率偏低，與C型的小區，由於要兩根SD掉話多，質差切換比正常小區多，切入成功率與接通率偏低。SD比例多；而直放站則是200站及
要注意TRU故障或天線偏差、交叉相關。
（SU、BSIC。

4. 安川變頻器v1000旁路中的trx觸點接的故障接點在哪，起什麼作用，圖中sa是什麼。

這是一個故障閉合點,出廠是短接狀態,沒有激活,用不上 就不用管他 變頻器嚴工 專來維修 銷售解決變頻各種問題

5. 移動通信專業面試時會被問到的問題及回答技巧

一方面面試時注意1，自我介紹一定要把握好時間，最好在2分鍾。
2，回答問題時要看著HR的眼睛。
3，當HR問到所學專業與應聘職位的關系時，最好保持中立。
4，大談特吹自己的實踐能力與優勢，肯定會有加分。
5，凸現自己的綜合素質及適應力。
6，向HR提問要先出風度，千萬不要問自己都覺得沒意思之類的問題。
7，不要隨便打斷HR的話，盡管她（他）會隨時打斷你的話。
8，如果你被HR問到無話可說，就不停的微笑和點頭。
9，做到以上八條，你會發現自己真的很想走人了，不過，相信很快就可以收到下一輪的面試通知。二方面一般專業知識會問以下這些：（給你套題吧，是移動的筆試題，你好好准備下）1. GSM網中，一個S2/2/2的基站最多可同時容納42個無線用戶的通話。
2. 移動通信系統目前採用_FDMA_、_TDMA_和_CDMA_三種多址方式，GSM採用FDMA/TDMA（或TDMA）多址方式。
3. GSM系統按照功能分為MSS、BSS和 MS等三部分。
4. 無線介面上CCCH包括 PCH 、AGCH 、RACH三類信道。
5. 常見的基站組網方式有 星 形、 鏈 形、 樹 形 和環形靈活組網。
6. 在GSM系統中，移動台(MS)與基站(BTS)間傳輸的數字話音信號速率為 13 Kbit/s, 移動交換局(MSC)與基站間傳輸的數字話音信號速率為 64 Kbit/s，因此在BSS 與MSC之間需增加碼型變換設備。
7. 分集技術是對付快衰落的有效方法，在眾多的分集技術中，我們目前在市區最常用的是
__空間分集__。在郊區最常用的是 極化分集 。
8. 切換一般是指MS在 通話 狀態（空閑、通話）下由於位置改變而要進行的行為。
9. 在GSM網中，一個2M最大能帶 15 個載頻。
10. 數字蜂窩PLMN可提供的業務分為基本業務和補充業務。二、判斷題：
1. 如果手機沒有SIM卡，就不能進行任何呼叫了。 （錯誤）
2. HLR中存儲著移動用戶識別號碼、訪問能力、用戶類別和補充業務等數據。（正確）
3. MSC尋呼被叫用戶時，一定是在整個VLR范圍發送尋呼命令。 （錯誤）
4. 移動用戶發起位置更新時，並非每次都由VLR分配新的TMSI。 （正確）
5. GSM900/GSM1800雙頻系統可以共用交換子系統和基站控制器，還可以共基站。（正確）
6. GSM網個人鑒權密鑰Kc存放在僅存放在HLR/AUC 里。 （錯誤）
7. TCH與SACCH組合時51幀為一復幀，控制信道組合時26幀構成一復幀。 （ 錯誤 ）
8. GSM蜂窩小區的覆蓋半徑在設計時，即使把功率輸出調至最大，地形再平坦，其覆蓋范圍也不可能超過35公里。（正確）
9. 在關機注冊中，手機只有受到系統證實消息才能關機 （錯誤）
10. 在空閑狀態時，可能進行軟切換 （正確）
11. 天饋線系統的駐波比要大於1.4. （正確）三、選擇題：
1、下面哪些信道類型屬於控制信道 A、C、D
A、AGCH B、TCH/F C、FCCH D、SACCH
2、一個S2/2/2的基站最多同時可容納多少個無線用戶在通話？ B
A、36 B、42 C、 48 D、 64
3、天饋系統駐波比變差的可能原因有：A、B、C、D
A.接頭沒有接好
B 接頭密封不好導致進水
C.天饋避雷器駐波大
D.饋線某處有折損
5、以下哪些措施是GSM系統用來提高頻譜效率的（ 1、2、4 ）
1）跳頻 2）DTX 3）信道編碼 4）功率控制
6、以下屬於雙向信道的是（ 1 ）
1）SACCH 2）AGCH 3）BCCH
7、上行鏈路的測量報告是在（ 3 ）上傳送的：
1）SDCCH 2）RACH 3）SACCH 4）FACCH
8、西門子MSC可以和MOTOROLA的BSC互連的原因是因為存在標準的（ 1 ）介面：
1）A 2）B 3）C 4）D
9、掉話與切換失敗有那些共同的可能原因： abcd
A 干擾程度較高 B 硬體有故障 C 天饋線聯接方向錯誤D 越區
10、 絕大多數情況下，基於小區擁塞的切換HOTRAFFIC是：b
A 服務小區的中心的手機用戶切換到其他小區上，以緩解擁塞；
B 服務小區的邊沿的手機用戶切換到其他小區上，以緩解擁塞；
C 將服務小區中新的提出信道佔用請求的用戶切換到其他小區上，以緩解擁塞。
11、處理切換失敗的思路： abcd
A 查干擾源 B 排除可能的硬體故障 C 減少小區間的交叉覆蓋區 D 排除設計上的不足（有同頻同BISC/同頻小區間互為鄰小區）
蜂窩的切換失敗的處理： e
A 調整頻率及BSIC設計 B 調整鄰小區的定義 C 查找室內分布系統的問題 D 切換門限的調節 E 以上均可以
11、 MS對目標小區進行重選時，不需要核對的信息是： d
A cro B Cell bar C Location Area D Time advance
12、 加快切換速度可以： bcd
A 切換成功率就會下降，
B 適當減少掉話，
C 切換量會增加，
D BSC負荷會增加
13、 掉話的原因： abc
A 干擾程度較高 B 硬體有故障 C 天饋線聯接方向錯誤
14、 處理掉話的思路： abcd
A 查干擾源 B 排除可能的硬體故障 C 減少或增加小區間的交叉覆蓋區 D 查天線的連接
15、 LAC區設置不當而導致的位置更新過多，手機可能會有什麼現象：d
A 手機有信號，被叫錄音提示不在服務區
B 手機有信號，無法作被叫
C 手機信號不穩
D 以上全是
16、 小區的信號很強但用戶不能起呼（可以切換進入）的原因：d
A 有強外部干擾 B 小區未在交換中定義 C 手機制式與GSM協議不匹配（如未升級的某些手機在開通DCS1800的區域）
D 小區未定義SDCCH信道。
20、位置更新中利用的邏輯信道是哪個：b
A，TCH B，SDCCH C，SACCH D，FACCH
21、解決位置更新過多的方法有：abd
A,重新規劃位置區
B,位置區邊界盡量避開小區重選頻繁的地段
C,給邊界處的小區多配置信令信道
D,修改CellReselectHysteresis參數
22、GSM網路採用900/1800MHz頻段，其中移動台發、基站收為：B
A 908-914MHz B 909-915MHz C 910-916MHz
25、當移動用戶使用分組數據業務的時候，需要給用戶分配IP地址。與核心網分組部分有關的設備也應當分配IP地址，例如：A C
A BSC 、PCF B PDSN、RADIUS伺服器和HLR C DNS伺服器、防火牆和各種應用伺服器
27、GSM/CDMA網內主叫號碼傳遞原則規定中，正確的是：A C
A網內話路接續過程中，原則上不對主叫號碼做變換 B GSM/CDMA用戶做主叫時，在網內主叫號碼格式採用國際有效號碼 C國內其他網的主叫號碼在接入聯通網的GMSC時變為標准格式，並在網內進行傳送
28、下面那些論述是錯誤的：ABC
A，鑒權過程在每次通話前或位置更新前均必定會發生。
B，Ciphering過程在每次通話前或位置更新前均必定會發生。
C，TMSI再分配過程在每次通話前或位置更新前均必定會發生。
D，交換中可以定義使鑒權過程， Ciphering過程，TMSI再分配過程使他們並非每次都發生。
30、手機正在通話狀態下，它切換進入了一個新的位置區中的小區，那麼： C
A，它會通話過程中進行位置更新。
B，它會在下次跨LAC區時進行位置更新。
C，它會在通話結束後馬上進行位置更新。
31、手機正常關機後，下列那些情況是正確的： C
A，系統仍舊會通過PAGING信道對它發出PAGING請求，雖然手機已經收不到了。
B，短消息被排隊到資料庫中，如果在用戶開機前還未被更新掉，短消息也不能發送到用戶。
C，其他用戶對該手機的呼叫請求會被拒絕。
D，發給它的短消息肯定會丟失。
32、下列那些描述是正確的： D
A，每次位置更新均需牽入HLR。
B，位置更新均發生在不同的VLR上。
C，幾類位置更新的優先順序是一樣的。
D，每次位置更新中均要改動用戶數據的存放位置或指引位置。
33、下列哪種技術不屬於抵抗多徑衰落現象： b
a) 信道編碼 b) DTX c) 跳頻 d)交織
34、TMSI再分配的主要目的是： A
A，防盜打 B，加密 C，漫遊 D，IMSI數量不夠時的補充。
35、解決位置更新過多的方法有： ABD
A,重新規劃位置區 B,位置區邊界盡量避開小區重選頻繁的地段
C,給邊界處的小區多配置信令信道 D,修改CellReselectHysteresis參數四、問答題
1、請列出切換失敗的幾種原因（請至少列出三種）
(1) 硬體問題（例如時鍾板出了問題，無法同步）
(2) 原小區存在干擾導致無法解碼HANDOVER COMMAND 的信息；目標小區存在干擾
(3) 孤島效應（同BCCH，BSIC）
(4) 要切入的目標小區信道資源短缺
(5) 惡劣的無線條件導致MS無法收到原小區的切換命令或無法佔用目標小區所指配的信道(惡劣的無線條件往往是由小區之間覆蓋重疊較少引起)
(6) 覆蓋問題：目標小區與源小區沒有足夠的重疊區域
(7) 由於天線受到阻擋或同一小區的兩根天線覆蓋不均勻導致
(8) 直放站放大了雜訊
(9) 參數設置問題：如T3103設置過小，導致MS沒來得及佔用上目標小區的信道
(10) A介面負荷過大產生擁塞，導致MSC內或MSC之間傳送切換請求和切換命令時無時隙可用。
MSC的LAC表定義不全。2、移動台為空閑模式下，移動台接收到小區1和小區2的信號電平如下：
AV_RXLEV = 26 in cell 1 , AV_RXLEV = 20 in cell 2
具體參數如下：
小區 1: TXPWR_MAX_CCH = 39 dBm
RXLEV_ACCESS_MIN = 20
CELL_RESELECT_HYSTERESIS = 4dB
小區2: TXPWR_MAX_CCH = 33 dBm
RXLEV_ACCESS_MIN = 14
MS是否執行小區選擇?
a) 如果是 phase 1 MS，小區1和小區2屬於同一個位置區
b) 如果是 phase 1 MS ，小區1和小區2不屬於同一個位置區
提供以下信息：
C1 = AV_RXLEV - ACCESS_MIN - Max (0, MS_TXPWR_MAX_CCH - P)
MS GSM900 Phase 1, power class 3 = 37 dBm.

CELL 1：C1=26-20-2=4
CELL 2:：C1=20-14=6
C1(CELL2)>C1(CELL1)進行小區重選
不同LAC:
當C1(CELL2)〉C1(CELL1)+ CELL_RESELECT_HYSTERESIS時，才進行小區重選

3、如果發現一個BS240基站宕機，而電源是好的，重新開關基站後發現基站仍然無法正常工作，試圖連接LMT也未能成功（假設LMT是好的），請分析一下，一般可能是什麼原因導致如此故障，並採取何措施進行恢復。
應為COBA負責LMT的連接功能，可能COBA損壞或備板損壞，需要更換COBA進行恢復；

4、BS240基站配置成8/8/8，硬體包括一個基本機架和兩個擴展機架。在開通過程中，發現三個機架CU模塊的創建很順利，但在創建擴展機架的DUAMCO時，總是不成功。無論嘗試多少次，系統是中提示DUAMCO的狀態是「not installed」。現假設機架的備板沒有問題，機架間相連的電纜也沒有問題。請解釋可能的原因。
ACT故障
合路器損壞
CAN BUS故障
COBA或COSA隱性故障
合路器背板故障
COBA合COSA背板故障
機櫃內部連線是否緊密選擇題
1，在GSM移動通信系統中，開放的通信介面有：（abd ）
a, Air介面
b, A介面
c, A-bis介面
d, O&M介面
2，在GSM移動通信系統中，空中介面使用的協議是：（ d）
a, LAPD信令 b, A-bis信令 c, CCS7信令 d, LAPDm信令
3，在呼叫時，用於進行鑒權和呼叫建立的信道有：（ b ）
a, FACCH
b, SDCCH
c, PCH
d, FACCH
4,鄭州市區一個GSM900的基站，可能的BCCH頻率為：（ bc）
a,29
b,83
c, 96
d,1020
5,三代站基站重啟過程中BCFA板停留在0006狀態，可能的原因有：（
cd ）
a,傳輸不通
b,傳輸通，但信令不活
c,信令活，下載軟體包
d,信令活，但BSC機房未加數據
6,開通三代站基站時，傳輸路由和傳輸板TRUA都沒有問題，但是基站傳輸板亮黃燈，可能的原因有：（ a ）
a,同步設置不正確
b,分支表設置不正確
c, TRUA跳線有問題
d,基站後背板跳線有問題
7,開通四代站基站的過程中，所有載頻停留在 狀態，可能的原因是：（ cd ）
a, BB2A有問題
b, BOIA有問題
c, traffic manager有問題

d, 傳輸板有問題
8,一對愛立信的微波，如果有一端的發射頻率為14930.00，那麼對端的發射頻率應該為（ a ）
a,14510.00
b,15350
c,13920.00
d,15940.00
9,開通一個微蜂窩基站，其傳輸從一個宏蜂窩基站做交叉連接分時隙並經過微波，開通之後本站載頻能夠工作，但是出2993告警，撥測無法佔用戶，可能的原因：（ d ）
a,微波故障 b,宏蜂窩基站傳輸板故障 c,微蜂窩基站傳輸板故障 d,宏蜂窩基站交叉連接故障
10,一個NOKIA微波，其電源指示燈亮黃燈，可能的故障原因有：（ad ）
a,時鍾未校準
b,饋線和室外單元故障
c,2M中斷

d,2M通路環路
11,下列那些單元可以生成13M時鍾：（ ac）
a, BCFA
b, MCLG
c, BOIA
d, VXTA
12,某個三代站載頻TRXA不能夠執行調頻功能，可能的故障點在：（a ）
a, BB部分
b, TX部分
c, RX部分
d, MCLG部分

6. 版本自動回退告警 如何處理

BTS312基站告警目錄 2114 LAPD告警 42116 TRX配置告警 62118
TRX處理器運行告警 72120 無線鏈路嚴重告警 82122 TRX降功率告警 92124
TRX關功放告警 102126 TRX內部收發通道告警 122134 無線鏈路提示告警
132136 測試鎖相環告警 162138 TRX單板ID錯誤告警 162140 鎖相環告警
172148 TRX硬體告警 182152 功放溫度告警 192156 TRX駐波告警
202166 TRX主時鍾告警 222168 TRX副時鍾告警 232170 DBUS告警
242176 TRX硬體邏輯不支持16K信令告警 252180 頻點與TRX類型不一致告警 262182
幀或時隙號告警 272188 主接收通道告警 292190 分集接收通道告警 302192
載頻類型不支持告警 312196 TRX時鍾嚴重告警 322198 鎖相環嚴重告警
342204 TRX單板通信告警 352206 TRX槽位單板配置錯告警 362208 時鍾參考源異常告警
372210 E1遠端自環測試告警 392214 E1本地告警 402216 E1遠端告警
412220 TMU郵箱故障告警 432222 TMU單板通信告警 442224 TMU軟體告警
452232 TMU時鍾故障告警 462234 主TMU時鍾故障告警 472236
擴展TMU時鍾故障告警 482244 版本回退告警 492248 防雷箱故障告警 502260
13M時鍾校準維護告警 512264 軟體未激活告警 522272 CDU駐波二級告警
532274 CDU駐波一級告警 552276 CDU主接收低噪放告警 562278
CDU分集接收低噪放告警 572280 CDU單板通信告警 582282 主接收塔放告警
592284 分集接收塔放告警 612286 CDU駐波嚴重告警 622292 EDU支路駐波告警
642294 EDU支路嚴重駐波告警 662296 EDU支路低雜訊放大器告警 672298
EDU支路塔放告警 682300 合分路器單板類型配置錯告警 702302 合分路器頻段與TRX頻點不匹配告警
712334 PMU單板通信告警 722354 風扇告警 732358 交流過壓告警
742360 交流欠壓告警 752384 EAC單板通信告警 762560 PBU過駐波告警
782562 PBU過溫度告警 792564 PBU欠功率告警 812574 PBU主時鍾告警
82

7. htcg10 水貨 串碼354455044959763 sn碼SH16TRX00549 哪位高人麻煩幫我查一下謝謝

產地上海，生產日期2011年6月26日。

授人以魚不如授人以漁，查詢方法如下：
S/N: SSYMDPPZZZZZ
SS為產地代碼：
SZ 深圳
SH 上海
HT 新竹
CH 武漢
Y: 生產年份的最後一個數字
M: 生產月份。123456789ABC代表1、2、3、4、5、6、7、8、9、10、11、12月
D: 生產日期。日是1～9～A～Z(26個字母中不使用到其中的四個"IOQU")代表1～9～10～31日)
1=1 2=2 3=3 4=4 5=5 6=6
7=7 8=8 9=9 10=A 11=B 12=C
13=D 14=E 15=F 16=G 17=H 18=J
19=K 20=L 21=M 22=N 23=P 24=R
25=S 26=T 27=V 28=W 29=X 30=Y
31=Z
PP:產品代碼
ZZZZZ:序號