Soci (Soczó Zsolt) szakmai blogja

2017.09.22.

Debugolás Visual Studio 2017-ben

Filed under: .NET,C#,Debugging,Szakmai élet,Visual Studio — Soczó Zsolt @ 16:02

.NET Core és VS 2017 alatt van egy újfajta debug symbol kezelési módszer, a source link.
Itt egy egyszerű leírás, hogyan kell használni.

Tök szépen lehet a core kódokat így debugolni, csak szokás szerint a lokális változók nem látszanak.

2014.03.26.

OzCode

Filed under: .NET,Debugging,Szakmai élet,Visual Studio — Soczó Zsolt @ 08:37

Mátyás Gergely hívta fel a figyelmem az OzCode nevű kis debugger ketyerére (utólag is köszönöm neki).

Az OzCode egy (egyelőre ingyenes) kis VS kiegészítés, ami a debuggert okosítja fel. Hogy miket tud nem írom le tételesen, a honlapján szépen összeszedték.

Amire nekem most jó volt. Elszállt az adatbázisba mentő kód.
Additional information: The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 59 (“@p56”): The supplied value is not a valid instance of data type float. Check the source data for invalid values. An example of an invalid value is data of numeric type with scale greater than precision.
OR mapper generálta az insertet, így nem tudtam, mi az 56. paraméter. A Hiberna belső batch-elője szállt el, amiben a jófene tudja hol vannak a commandok és a paraméterek.
Sebaj, itt jön az OzCode. A referenciára ráállva rákerestettem a @p56-ra, erre végigkeresi az ojjektumból kiindulva a referenciákat, és meg is találta benne:

Nem csak a memberök nevére keres, hanem a változók tartalmára is, a @p56 is egy insert string belsejében volt!
Az insertet megnézve látszott, hogy ez a Fitness nevű propertyre képződik le. Feljebb menve a stacken ismét kerestettem egyet:

Gyönyörűen látszik, hogy NaN a double property értéke, ez nem tetszett az SQL Servernek, ő nem tud ilyet ábrázolni.

Barátunk az OzCode.

TDD tanfolyam

2012.07.25.

Test Driven Development – I like it

Egyre több dolgot TDD módon írok meg. Ami szembetűnő a korábbi, először implementálok aztán ha van rá idő írok hozzá tesztet (nem fogok) módszerhez az a következő:
-Sokkal kevesebbet, nagyon sokszor egyáltalán nem debugolok. Ez eszement sok időt spóroló tevékenység, gyűlölöm, amikor 2-3 percet is nyomkodok, mire eljutok a betegnek vélt ponthoz a debuggerben. Ott aztán sokszor kilép a debugger (pont timeoutolt a web worker process), release kód miatt nem mutat változókat, továbbléptetem, aztán kezdhetem elölről (lehet mozgatni a current pointert, de ha már okoztunk mellékhatásokat hiába megyünk vissza), stb. Szeretem az advanced debuggung témát, de utálom az időt vele feleslegesen tölteni.
-A GUI-t alig indítom el, ezáltal megint nagyon sok időt takarítok meg.
-Az implementált dolgaim azonnal mennek, amikor a GUI-t is elindítom, már csak élvezni kell az eredményt.
-Hamarabb készen vagyok a feladattal. Tudom, ezt nem lehet objektíven mérni, mert nincs mihez viszonyítani. De az első két pont miatt érzésre annyi időt megtakarítunk, ami felülmúlja a tesztekre szánt időt.

Igazából a TDD nem is a tesztelésről szól. Ez komplexitás és félelem kezelés. Arról szól, hogyan implementáljuk egy bonyolult feladatot sok kicsit változaton keresztül úgy, hogy ne őrüljünk bele, ne legyen sok kudarcunk. Az már csak egy plusz, hogy sokkal jobb lesz a kódminőség.

2010.11.26.

.NET Stringek lementése Memory Dumpból

Filed under: .NET,CLR,Debugging,Szakmai élet — Soczó Zsolt @ 11:02

Mostanában elég sokat turkálok problémás webappok dumpjában. Leírom magamnak is, hogy lehet lementeni .NET stringeket a dumpból.
WinDbg dolgok következnek.

A nagy stringeket kilistáztatom a
!DumpHeap -min 100000 -type System.String
paranccsal.

Valamelyik heapről kinézek magamnak egyet, és az előbbi parancs kimenetének első oszlopában található címet felhasználva belenézek a du cím paranccsal.
Pl.
0:000> du 5ce31140
5ce31140 “*****<sitecore database=”SqlSer”
5ce31180 “ver”>.. <sc.variable name=”da”

Az elején a kuszaság (átírtam csillagokra, mert elrontotta a htmlt) a .NET Stringek adminisztrációja és az object header.
Ha szemre tetszik a string, akkor pl. ki akarom menteni fájlba.
Nézzük meg a szöveges rész előtti bináris részt (dd).

0:000> dd 5ce31140
5ce31140 793308ec 00040001 0002836c 0073003c
Az első 8 byte az object header (32 biten, 64-en ez asszem 16 byte), sync block és type leíró. Számunkra ez érdektelen. A 3. dword már érdekesebb, ez a string hozza karakterekben. Azaz bájtban ennek a duplája, mert 2 bytes unicode ábrázolást használ a .net.
Így stringünk hossza 0002836c*2 byte. A 0073003c már a < karakter (003c) és az s betű (0073), szokásos fordított Intel sorrendben. A szöveges tartalom tehát a 5ce31140+0c címen kezdődik (headert átlépjük), és 0002836c*2 a hossza. A tartalom fájlba írása már egyszerű: .writemem c:\temp\s1.txt 5ce31140+0c L0002836c*2 Kedvencem a WinDbg, de ezt már mondtam. :)

2010.05.10.

Disable/turn off “Attach Security Warning” in Visual Studio

Az RC óta elfelejtettem, hát leírom magamnak.

Home Windowsokon nehézkes IIS-ben fejleszteni

Filed under: Debugging,IIS,IIS7,Szakmai élet — Soczó Zsolt @ 10:17

Nincs bennük Windows Auth, így nem megy a debugging se. Ref. Nagy cumi ez. Ha valaki tud rá megoldást, érdekelne. (Nekem ultimate-em van, így nem gond, de már a 2. ismerősöm fut ebbe bele.)

2008.12.11.

Debugolás a .NET fw. forrása segítségével

Filed under: .NET,C#,CLR,Debugging,Szakmai élet,Visual Studio,VS 2008 — Soczó Zsolt @ 12:32

Kaptam egy igen nehezen megközelíthető problémát, amelyben a fókusz a TAB-ra átlépett egyes controlokat. Nem egy triviális TabStop=false probléma volt.
VS 2005-ös projektekről van szó, átkonvertáltam őket 2008-ra, hogy tudjam a fw. forráskódját is debugolni. Az _NT_SYMBOL_PATH= nekem be van állítva a gépen a publikus os szimbólumokra (elsősorban ahhoz amikor WinDbgozok), emiatt nem tudtam a vsből .net fw.-öt debugolni, mert előbb lehúzza a stripped szimbólumokat, a teljeshez már hozzá se nyúl. Ezért egy bat-ból indítom a vs-t, előtte kiütve az eredeti _NT_SYMBOL_PATH-t.
Így már ment a fw. forrás debug, de mivel a clr az ngenelt optimalizált kódot töltötte be, ezért nagyon sok típus belseje nem látszik normálisan. Erre megoldás itt található. Le lehet tiltani, hogy a CLR az ngenelt kódot töltse be, így már rendesen lehet debugolni.
Lehetne, ha nem lenne elcsúszva némelyik forráskód a pdb-ben található sorszámoktól. Ilyenkor van az, hogy teljesen más sorokon lépkedünk végig, mint amit a source ablakban látunk, pl. kommenteken lépked végig a debugger.
A megoldás erre egyszerűbb volt, mint gondoltam volna: próbaképpen kitöröltem 3 sort pl. a Control.cs elejéből, így visszaállt a szinkron.
Maga az alapprobléma egyébként abból adódott, hogy egy kompozit Third Party Contol explicit letiltotta
a TAB-olást, a ControlStyle-ból kivéve a Selectable flaget.

2008.09.25.

symsrv.ini

Filed under: Debugging,Szakmai élet — Soczó Zsolt @ 16:11

Natív debugolásnál bosszantó dolog, ha sok nem ms dll is be van töltve egy processzbe és használjuk az ms symbol szervereit, mert minden egyes processzhez hozzácsatlakozva a debugger megpróbálja letölteni a hiányzó szimbólumokat, de mivel azok nincsenek az ms szerverein, ezt minden egyes alkalommal eljátssza.
Mivel én rendszeresen az IE-ben debugolok, az meg olyan mint egy bolhafészek annyi dll van beletöltve, ezért nagyon bosszantó vagy egy percet várni mire végignéz minden dllt a debugger. A google élen jár ebben, teleszarja a dlljeivel a böngészőt.
Ezen segít a symsrv.ini. Fel lehet benne sorolni azokat a neveket, amelyekhez nem akarunk symbol szervert használni, így nem kutakodik feleslegesen a hálón a debugger.
Időnként érdemes fiddlerrel megnézni a forgalmat debugolás közben, így látjuk, mit akar feleslegesen letölteni a debugger, ezekkel lehet frissíteni a listát.

Nálam most így néz ki az ini:

[Exclusions]
rasapi32*
dbghelp.pdb
symsrv.*
mso*
google*
Tortoise*
libapr_tsvn*
libaprutil*
libapriconv_tsvn*
intl3_svn.dll
_tbl_simple*
windows-1252*
utf-8*
ssv*
Jccatch*
IEDevToolbar*
SLC*
gears*
WindowsLiveLogin*
msidcrl40*
SelectorObjectAPI*
GoopdateBho*
atiumdag*
atiumdva*
flash*
gzip*
AcroIEHelper*
swg*
wngtrace*
wmv*
vfbasics*
vrfcore*
goop*
wpdshext*
WMVCORE*

2008.08.05.

Windows Internals vizsga – tapasztalatok

Filed under: Debugging,Könyvek,Szakmai élet,Vista,Windows,Windows Server 2008 — Soczó Zsolt @ 22:16

Voltam, láttam, visszamennék :) Ahogy várható volt ez nem az a vizsga, amit 2 nap tanulással le lehet tenni. A Windows Internals könyvből 3 fejezetet tudtam megemészteni ennyi idő alatt, így az azokkal kapcsolatos kérdésekre tudtam is kb. a válaszokat. Ha valaki elolvassa, megérti és kipróbálja a gyakorlatokat a könyvből, akkor szerintem a kérdések kb. 70%-ára tudni fogja a választ.
A maradék 30-hoz általános API programolási ismeretek, windbg igen alapos ismerete és a device driver programozás egyes részletei szükségesek. Emellett tudni kell kékhalált analizálni, érteni az IO műveleteket kernel módban, IRQ-kkal kapcsolatos debugolásokat, dumpokat elemezni, verifierrel vegzáni drivereket, paged, nonpaged, stb. memóriákat elemezni, heap corruption-öket debugolni, lefagyott vagy lerohadt user módú appokat debugolni, kernelből visszahívni user módba, szervizeket piszkálni, leak-eket analizálni, különböző utilokat ismerni (umdh, procexp, tlist, kernrate, sc, gflags, stb.), 64 biten 32 bites cuccok futtatása, UAC jobbra-balra, DEP, memory mapped files, IO completion portok, named pipe-ok, file-ok kezelése szinkron és aszinkron módon, Credential api, perfmon, pool tagging, kernel profilozás, power események kezelése device driverből, kernel struktúrák debugolása, azokból infók kibányászása (nt!_KWAIT_BLOCK, _DISPATCHER_HEADER, stb.), P&P eszközök debugolása, user és kernel módú szinkronizálás, aszinkron IO programozása driverben, kernel szálak kezelése, IRQL szintek és azok jellemzői, Deferred Procedure Call programozása, DMA kezelés, védett módba lépés különböző processzorokon, kézzel lekreseltetni a lefagyott oprendszert (dump céljából), checked buildű kernel hozzáadása éles géphez, filter driverek problémái, stb, stb. Most több nem jut az eszembe. Kb. 3/4 rész kernel, és 1/4 rész user mód volt benne. A kérdések legalább a fele a WinDbgről szól. Ezzel nem is lett volna baj, ő az új szerelmem már pár hónapja (sokkal többet tud, mint a vs debuggere), de én eddig user módban debugoltam. Igaz, hétvégén összehoztam egy kernel debug sessiont a 64 bites gépen, orgazmushoz közeli érzés CTRL-Break-kel megállítani az oprendszert, és beleesni a kernel debuggerbe. Majd ha e helyett már unalmat érzek, akkor érdemes elmenni erre a vizsgára (ez kicsit kétértelmű lett. :).
Szóval korrekt, de nehéz kérdések voltak.

Feltett szándékom, hogy azért is megértem mi történik a Windowsban, és megcsinálom a vizsgát, majd később, pénzért (ez most ingyenes beta volt). Ami nekem még előnyöm a MVP-ként a Windows forráskód hozzáférés, majd ha a kernelt tudom forrásszinten debugolni, az is egy újabb hőhullámot fog kiváltani. :) User mód már megvolt, az is egy élmény forrásszinten.

A tanuláshoz a következő könyveket és forrásokat szándékozok bevetni:

Első körben ennyi. Már csak pár évnyi éjszaka kell, és túl is vagyok rajtuk. :)

2008.07.09.

Küzdelem az SQL Server 2008 RC0 telepítővel (debug war)

Filed under: Adatbázisok,Debugging,SQL Server,SQL Server 2008,Szakmai élet — Soczó Zsolt @ 10:41

Hetek óta nincs SQL Serverem (jó, időm se volt), mert nem ment fel az RC0. Egyes komponensek nem mentek fel, pl. a database engine, ami azért hiányzott.
A probléma oka nyilvánvalóan az volt, hogy fenn volt előtte a februári CTP, ami odaganézott a merevlemezre ide-oda.
Ezért bőszen nekiálltam feszítővassal, lángvágóval, és kiszedtem az általam azonosított maradványokat a registryből, a fájlrendszerből, gacból. Erre ilyen hiba kezdett jönni:

2008-07-08 22:19:22 Slp: Microsoft.SqlServer.Setup.Chainer.Workflow.ActionExecutionException: MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code = '{7D3F6746-94DE-4E1F-94F9-933B68EB68C4}'. Error code: 1605. ---> System.InvalidOperationException: MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code = '{7D3F6746-94DE-4E1F-94F9-933B68EB68C4}'. Error code: 1605.
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Configuration.MsiExtension.SetFeatureInstallStateAction.FillInstallPropertyByProductCode(PackageInstallProperty pkg, String prodCode)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Configuration.MsiExtension.SetFeatureInstallStateAction.FillInstallProperty(PackageInstallProperty pkg)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Configuration.MsiExtension.SetFeatureInstallStateAction.ExecuteAction(String actionId)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Chainer.Infrastructure.Action.Execute(String actionId, TextWriter errorStream)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Setup.Chainer.Workflow.ActionInvocation.InvokeAction(WorkflowObject metabase, TextWriter statusStream)
2008-07-08 22:19:22 Slp:    at Microsoft.SqlServer.Setup.Chainer.Workflow.PendingActions.InvokeActions(WorkflowObject metaDb, TextWriter loggingStream)

Google nem adott kézzelfogható eredményt.

Reflectorral megnéztem, mi történik ezekben a metódusokban?

private void FillInstallPropertyByProductCode(PackageInstallProperty pkg, string prodCode); 
Declaring Type: Microsoft.SqlServer.Configuration.MsiExtension.SetFeatureInstallStateAction 
Assembly: Microsoft.SqlServer.Configuration.MsiExtension, Version=10.0.0.0 

Ez a kód a gyanús benne:

errorCode = MsiNativeMethods.MsiGetProductInfo(pkg.ProductCode, “Language”, lpValueBuf, ref capacity);
if (errorCode != 0)
{
throw new InvalidOperationException(SR.MsiGetProductInfoFailedToRetrieveProductVesrionByProductCode(pkg.ProductCode, errorCode));
}

Ismer valami ProductCode-ot, ennek akarja lekérni a verzióját, de nem sikerül, mert kézzel már leirtottam a darabjait.

Honnan veszi a beteg ProductCode-ot? CTRL-R, analyze. Itt hívják meg a fenti metódust:

private void FillInstallProperty(PackageInstallProperty pkg);

Ebben:

installedProductCodeList = this.msiMetadata.GetInstalledProductCodeList(packageAttributes);
if ((installedProductCodeList != null) && (installedProductCodeList.Count > 0))
{
this.FillInstallPropertyByProductCode(pkg, installedProductCodeList[0]);
}

Szóval a GetInstalledProductCodeList adja vissza a rossz prod code-ot. Ő belül ezt hívja meg:

errorCode = MsiNativeMethods.MsiEnumRelatedProducts(packageUpgradeCode, 0, iProductIndex, lpProductBuf);

MsiEnumRelatedProducts, ez adja vissza a baromságot. Ez már natív függvény, az MSI.DLL-ben. Elő a debuggerrel! Nem, nem a VS-re lesz szükség, az kis gyík a nagytesóhoz, a WinDbg-hez képest, ehhez az kevés.

UINT MsiEnumRelatedProducts(
  __in   LPCTSTR lpUpgradeCode,
  __in   DWORD dwReserved,
  __in   DWORD iProductIndex,
  __out  LPTSTR lpProductBuf
);

WinDbg-vel töréspont beállít a fenti függvényre. A törésponthoz be lehet állítani akciót a WinDbg-ben, ebben kiíratom a függvény első és 4. paraméterét, az 1-re keres rá, a 4.-ben jön vissza a baromság.

bu msi!MsiEnumRelatedProductsW+0x64 "du poi(esp+0x4);du poi(esp+0x10);g"

Ez a breakpoint szintax. Breapoint Unresolved (szimbolikus, futás közben oldja fel), az msi.dll MsiEnumRelatedProductsW függvényére, de nem a belépési pontjára, hanem 64h offsettel hátrébb (ez a függvény ret utasítása, azért ez kell, mert itt már ki van töltve a 4. paraméter).
Az akció rész idézőjelek között van, ez fut le, ha becsap a töréspont. du: dump unicode data. A poi feloldja az ESP+4 címet, onnan írjuk ki a stringet. Ugye ESP a visszatérési címre mutat, ESP+4 az első paraméterre, ami egy LPCTSTR, esetünkben LPCWSTR, ezt oldja fel a poi, a du meg kííratja. A 10h címen van a 4. paraméter. A g parancs futtatja tovább a kódot, azaz a töréspont valójában csak kiírja a számomra szükséges infókat, és a program fut tovább.

{65A00972-4629-4343-AAF7-9C35CE25CD84} erre kérdeznek rá, és {7D3F6746-94DE-4E1F-94F9-933B68EB68C4} rá a válasz, pont, ami a hibaüzenetben is jött.

No, honnan a francból szedi fel a 65A00972… GUID-ot? Bármennyire is bosszantó, se a fájlrendszerben, se a registryben nem találtam meg azt a kódot. Fukk.

Elő a procmonnal. Ugye az a gond, hogy detektál valami darabkát egy korábbi verzióból, de az MSI-ket már nem leli hozzá. Beállítottam szűrési feltételt, hogy a setup100.exe process név és a Path tartalmazza az UpgradeCode stringet. Kiderült, hogy miután megtalálja ezt:
HKEY_CLASSES_ROOT\Installer\UpgradeCodes\27900A5692643434AA7FC953EC52DC48
leáll a telepítés. Ezek szerint ez valami korábbi SQL Server verzió darabja lehet. Átneveztem ezt kicsit, hogy ne találja meg a telepítő. Ettől továbbment a telepítő, de befagyott. Kiirtottam az összes keresett UpgradeCode-ot és voalá, sikeresen felment a szerver.

Finnyás egy kis köcsög lett ez a verzió. Jó, tudom, nem illik szétszabni kézzel a registry-t, de akkor is. :)

2008.01.17.

A nap híre: .NET Framework Library Source Code now available

Filed under: .NET,CLR,Debugging,Szakmai élet — Soczó Zsolt @ 13:54

Ma mindenkinél erről lehet majd hallani, örülünk, böngészünk, debugolunk.

2007.04.21.

Natív kód debugolási útmutató 10 percben

Filed under: Debugging,Szakmai élet — Soczó Zsolt @ 15:26

Szeretnék némi segítséget adni azoknak, akik nem általuk írt natív kódot szeretnének debugolni. A példában az Internet Explorert debugolom meg.
A natív kódú debugolás reménytelen szimbólumok nélkül, amelyek pdb fájlokban laknak. Az MS minden moduljához publikál pdb fájlokat, amelyek persze forráskód információt nem tartalmaznak, de a függvények és osztályok neveit igen. Ezek a stripped pdb fájlok.
Egy dll-hez, exe-hez a hozzá pontosan passzoló pdb fájlra van szükség. Kézzel igen nehéz lenne minden fájlhoz összevadászni a szimbólumokat, főleg, hogy hetente jönnek a hotfixek a gépre. Ezen segít a symbol szerver. Ez azt jelenti, hogy az ms minden modulhoz kirakja nyilvánosan egy webszerverre a szimbólumokat, amit a WinDbg vagy a VS magától le tud tölteni.
A szimbólumszervert be lehet állítani az _NT_SYMBOL_PATH környezeti változóban, vagy a VS-ben a Tool/Options/Debugging/Symbols alatt.
Visual Studio 2005 Debug Symbol beállítások
Nálam így néz ki a könyezeti változó:
_NT_SYMBOL_PATH=SRV*D:\Debugging\symbols*http://msdl.microsoft.com/download/symbols
D:\Debugging\symbols, ide tölti le a debugger a symbol fájlokat, így az első debugolás lassabban indul el, de utána már ebből a cache-ből veszi a pdbket.
Nálam ez a könyvtár 600 mega, ebben az XP és a Vista szimbólumainak egy része lakik.
Jöhet a debugolás. Az igazi macsó debugolás WinDbg vagy NTSD alatt lehetséges, én egyelőre a VS-re mutatom be, de már tanulgatom a WinDbg-ot is.
Létrehozok a VS-ben egy új, üres solutiont, így a töréspontok megmaradnak a debugolások között.
Debug/Attach-csal hozzákapcsolódok a már futó processzhez, esetünkben az IExpolere.exe-hez. Mivel fut a debugolandó program, így sokat nem tudunk vele tenni, állítsuk meg: break gomb a toolbaron, vagy F12.
A Modules ablakban látszanak a betöltött modulok és a hozzájuk tartozó szimbólum infó.
VS 2005 Modules ablak
A következő lépés töréspontok beállítása. Mivel nincs forráskódunk, ez kicsit macerásabb, mint saját kódoknál, de nagyobb az öröm is, ha sikerül összehozni. :)
Pl., a diagnosztizálandó probléma miatt engem érdekel, ha a registryből akar egy értéket olvasni az IE. Ezt valszeg a RegGetValue hívásával teszi meg. Rakjunk erre egy töréspontot!
A doksiból látjuk, hogy a RegGetValue 7 paraméteres. Ez azért fontos, mert az exportált nevek kicsit meg vannak gyúrva, így csak a függvény nevével nem lehet töréspontot berakni. A mangled név így néz ki általában az api függvényeknél (x86): _Fv@a paraméterek összmérete. Így a RegGetValue neve: _RegGetValueW@28 (7×4). A befagyaszott kódban a Breakpoints ablakban, New Breakpoint-tal már be is rakhatjuk a töréspontot:
VS 2005 Breakpoints ablak, benne 3 törésponttal
Ha tele, piros kört látunk, örülünk, ha nem, újragondoljuk a nevet.
Ezután a kódot elindítva előbb-utóbb becsap a kívánt töréspont:
Becsapott a töréspont :)
A képen sokkal több látszik, mint egyszerűen a töréspont. A bal oldalra dokkolt Memory 1 fenti kombójába beírtam, hogy ESP, így ráált a veremmutató címére, azaz az ablak tetején a fv. hívás lokális paraméterei láthatók. A legfelső érték a visszatérési cím, a másik az első paraméter, stb. Kijelöltem a 76daa4b8 paramétert, ami a RegGetValue LPCTSTR lpValue paramétere, azaz egy string mutató, esetünkben Unicode, mert Vistán vagyunk. Rádobtam a Watch ablakra, és átkasztoltam wchar_t*-gá, így azonnal látható lett az értéke. Hasonló módon a Memory 2 kombójába is beledobtam az értéket, így ott is látható a string.
Bajban vagyunk a töréspont szintaxisával, ha Template-et használó osztályokban kell töréspontot beállítani. Ilyenkor a fenti kukacos, számolós eljárás nem jön be, nincs mese, bele kell kukkantani a pdb-be.
A DIA sdk-ban (a VS setup része, ha kérjük) vagy egy kis példa, DIA2DUMP a neve. Ezt lefordítva egy pdb dumpoló eszközt kapunk a kezünkbe.
Engem az urlmon.dll belseje érdekelt. A Modules ablakból tudom, melyik konkrét pdb tartalmaz hozzá infót. Ezután egyszerűen a pdb könyvtárából:
dia2dump urlmon.pdb >dump.txt
A dump 9 mega. Az elejéből megtudhatjuk hol voltak az obj fájlok a MS build gépén, amin a Vista RTM készült:

0001 f:\vistartm.obj.x86fre\shell\lib\cul\objfre\i386\precomp.obj
0002 f:\vistartm.obj.x86fre\inetcore\lib\stock\stock\objfre\i386\stock.obj
0003 f:\vistartm.obj.x86fre\inetcore\urlmon\mon\daytona\objfre\i386\mon.obj
0004 f:\vistartm.obj.x86fre\inetcore\urlmon\trans\daytona\..\..\mon\daytona\objfre\i386\trans.obj
0005 f:\vistartm.obj.x86fre\inetcore\urlmon\iapp\daytona\..\..\mon\daytona\objfre\i386\iapp.obj
0006 f:\vistartm.obj.x86fre\inetcore\urlmon\download\daytona\objfre\i386\cdlpch.obj
0007 f:\vistartm.obj.x86fre\inetcore\urlmon\zones\daytona\objfre\i386\zonepch.obj

018D f:\vistartm.obj.x86fre\inetcore\inetcommon\commonparse\objfre\i386\add2strw.obj

Majd jönnek a szimbólumok:
PublicSymbol: [000a7201][000a7201][0001:000a274d] _OutputBlock@4(_OutputBlock@4)

Én a Call Stack ablakból láttam, hogy a Cwvt::InvokeWinVerifyTrust metódus működése érdekel. Rákeresve a dumpban a InvokeWinVerifyTrust-ra ez a szimbólum jön fel:
?InvokeWinVerifyTrust@Cwvt@@AAEJPAXPAUHWND__@@KPAPAU_JAVA_TRUST@
@PBGPAUIInternetHostSecurityManager@@3PADHPAVCDownload@@@Z
(private: long __thiscall Cwvt::InvokeWinVerifyTrust(void *,
struct HWND__ *,unsigned long,struct _JAVA_TRUST * *,
unsigned short const *,struct IInternetHostSecurityManager *,
unsigned short const *,char *,int,class CDownload *))

Durva? Nagyon. Ez egy szimbólum, egy sor, csak betördeltem. Sajnos a template-ek miatt a compiler nagyon ronda cuccot rak össze, de normális emberek nem is nézegetnek ilyesmit. :)
Ám akármilyen hosszú is, a Breakpoints ablakba bepasztázva rátalál a VS és töréspontra, és meg is áll ott.
Szeretném hangsúlyozni, hogy ehhez a debugoláshoz NEM használtam a forráskód elérésemet, tisztán a mindenki számára elérhető publikus szimbólumokkal dolgoztam. Más kérdés, hogy a hiba felderítéséhez nagyban segít, hogy közben egy másik gépen és monitoron olvasom a forrást. :)
Ha sikerült valamit kinyomoznom a nagy debugolással, elmesélem. Ha nem, megtanultam jobban debugolni, és ti is kaptatok ízelítőt belőle.
Ja, és a témában az alapmű: Debugging Applications for Microsoft .NET and Microsoft Windows. Az új rész már csak manazsolt kóddal foglalkozik, erre figyeljetek.
Update: lett eredménye a 3 napos debugozásnak: az ActiveX Installer Service-szel fel se veszi a kapcsolatot az IE, ha az IE egy LUA account nevében fut. LUA: admin, de nem admin, azaz be van kapcsolva az UAC és az illető user tagja az admin csoportnak. Én ilyen voltam, és azt hittem, hogy emiatt minden program úgy kezel engem, mintha mégse volnék admin. Nos, az IE kódjában van egy elágazás, ami ez alapján másképp végzi az ActiveX telepítést. Így jártam, Zokszigen röhög, hogy még 2007-ben se vagyok igazi nonadmin, csak LUA luzer. Azt hiszem ez meggyőzőtt, hogy valódi nonadminként kell fejlesztenem. Vagy elég csak így tesztelni? ;)

2007.03.27.

Edit and Continue – hasznos-e?

Filed under: .NET,C#,Debugging,Szakmai élet,Testing,VS 2005 — Soczó Zsolt @ 13:00

Annak idején, még a VS 2005 illetve a .NET fw. 2.0 tervezésekor szó volt róla, hogy a C#-ban lesz refactoring (ez ugye csak VS fícsör), a VB-ben nem. Cserébe a VB-ben lesz Edit and Continue, de a C# nem kap ilyet.
Akkor az volt az érv, hogy a C#-osok komoly emberek, akik naphosszat refactorolnak, de nem hekkelnek a debugolás alatt álló kódon, mert az gagyi. De aztán a C# lobbi belerakatta.
Most, hogy C++-ban dolgozok, ahol már a VC6 óra van E&C elég sokat használom. Azért, mert gyakran van, hogy valami apróságot elszúrok, és mire azt a kódot újrafuttatom, sok időt veszítenék. Egyébként egy IE addont írok. Tudom, ha lennének jó Unit tesztjeim, akkor pikk-pakk újra lehetne futtatni a kódot a vizsgált pontig, de nincsenek, C++-ban még nem értek a Unit teszteléshez.
Szóval értem az érvet, komoly, unit tesztekkel felvértezett programoló nem használja az EC-t, de én úgy látszik nem vagyok az, így örülök neki, hogy van.

Amikor év elején egy C# kódot gyúrtam át, akkor nem is emlékszek, hogy használtam volna, de ott volt valag sok unit tesztem.
Ti használjátok, vagy komoly programolók vagytok? :)

2007.03.07.

Hogyan kell Vista alatt szervizeket debugolni?

Filed under: Debugging,Szakmai élet,Vista — Soczó Zsolt @ 14:52

Ha Vista alatt akarunk szervizt debugolni bajban vagyunk, mert másik sessionben fut, mint a debuggerünk (az UAC miatt).

A megoldás remote debugging (lehet van más is), itt leírják, hogyan kell ezt megtenni.

2006.09.17.

Szeretnék én így debugolni, mint ez a Russinovich gyerek

Filed under: Debugging,Szakmai élet — Soczó Zsolt @ 13:25

Mark első és ezidáig egyetlen bejegyzése, mióta a sötét oldalhoz csatlakozott. Nagyon jó nyomozás miért indultak el lassan a processzek a gépén. Imádom az ilyen nyomozós cikkeket, nagyon sokat lehet belőlük tanulni.

Powered by WordPress