Jump to content

assertion failure @ wind.cpp-1161


brsscreen

Recommended Posts

after missing scripted backup (computer off), i started manual backup (win me, onstream adr 50 external); unit mounted & selected incremental files in normal manner, but just kept "locating"; when i closed retrospect error message box appeared: assertion failure @ wind.cpp-1161; i tried restart & another tape; i could find nothing on database or FAQ; call to support said to post here rather than try tech incident; thanks for your time

Link to comment
Share on other sites

From the Knowledgebasecolor=blue>

 

 

 

Tech Note NO. 307 WINDOWS INTERNAL CONSISTENCY CHECK AND CONFIGURATION ERRORS

 

 

 

Windows assert, chunk checksum, exception, and access violation errors

 

 

 

Retrospect performs internal integrity checks during normal operation. Should one of these checks fail, Retrospect may report an "assert" or "chunk checksum" error, and halt operation. Similarly, if Retrospect crashes, you may receive an alert from Windows saying that Retrospect caused an "exception" or "access violation." All of these errors indicate a problem. This note will help you figure out what to do if you encounter them.

 

 

 

 

 

Definitions

 

 

 

A few definitions will help clarify the terminology:

 

 

 

- Assert error: An "assert" error results in a dialog put up by Retrospect that halts operation. The dialog is the result of an internal consistency check in Retrospect that has failed. The only choice at this point is to quit Retrospect.

 

 

 

- Chunk checksum error: Retrospect stores information in its backup set catalogs in "chunks" of data, each stored with a checksum, a number that helps verify data integrity. When Retrospect reads a chunk of data (for example when opening its configuration file, or reading file information out of the backup set catalog during the Matching step of a backup), it quickly verifies the data read from its own file and verifies that it matches the checksum originally stored with the data. If the data no longer matches the original checksum, it has become corrupt, and Retrospect reports a "chunk checksum" error. Typically this type of error occurs only with a specific backup set, or on launch, if your main configuration file has become corrupt.

 

 

 

- Exception and Access violation errors: These are errors reported by Windows when Retrospect crashes.

 

 

 

When experiencing one of these errors it is very important to restart the computer following each error message. Running Retrospect immediately following an error of this type without a system restart may leave Retrospect or even Windows in an unstable state.

 

 

 

 

 

Troubleshooting Tips

 

 

 

Search Online Dantz Resources

 

 

 

First, search the Dantz online Knowledgebase (found at www.dantz.com/support) for the error code reported. For example, if Retrospect stopped with an assert error with the text "module.cpp-457", search the web database for this phrase. If the error you are experiencing is a known issue, you will find an entry, along with instructions for recovering from the error. This note also contains a list of known assert errors. Search the list at the end of this document to see if the error you are experiencing is in our known list.

 

 

 

If the Knowledgebase does not have an entry for the problem you are experiencing, you may also want to try searching our Forum, also accessed via the web site.

 

 

 

If you cannot find a posting regarding the specific error, the information below will help you troubleshoot further.

 

 

 

 

 

Further Troubleshooting

 

 

 

First, identify when the error occurs. The most important step in identifying the source of the problem is to identify what operation or action is happening when the error occurs. Below are general notes on the following operations:

 

 

 

- Launching Retrospect

 

- Scanning for devices, or opening the Configure>Devices window

 

- Scanning a source volume in a backup or duplicate operations

 

- Starting a backup/Updating Catalog...

 

- Matching during a backup

 

- Matching during a restore

 

- Preparing for Disaster Recovery

 

 

 

Launching Retrospect

 

 

 

If you get the error while launching, your configuration file may be corrupt. Fortunately, Retrospect makes a backup of your configuration file each time you quit. You may be able to simply swap the backup file for the corrupt file and continue normal operation. We recommend that you rename the possibly corrupt file, and not throw it away until you have resolved the problem.

 

 

 

Retrospect for Windows stores its configuration files in the following locations:

 

 

 

Retrospect 6.0:The Config60.dat and Config60.bak files are located at C:\Documents and Settings\All Users\Application Data\Retrospect

 

 

 

Retrospect 5.6/5.5:The Config55.dat and Config55.bak files are located by default at C\Program Files\Dantz\Retrospect.

 

 

 

5.15 and earlier: The Config5.dat and Config5.bak files are located by default at C:\Program Files\Dantz\Retrospect.

 

 

 

Try renaming the ".dat" version (for example, put an "a" in front of the name), and then renaming the ".bak" version to end in ".dat". Relaunch Retrospect. If the error is gone, your configuration was corrupt. If the error continues, your backup configuration file may also be corrupt. If this happens, try removing all versions of the config file to another folder, and then relaunch Retrospect. You will be forced to enter your license code. If Retrospect launches fine, then both your live and backup configuration files were likely corrupt. You may wish to restore a configuration file that you have in one of your backup sets from a point before the error started occurring. If the problem continues, even with a clean configuration file, please contact Dantz Technical Support for further assistance.

 

 

 

Scanning for devices, or opening the Configure>Devices window

 

 

 

If you get the error while scanning for Devices, or when opening the Configure>Devices window, the problem is likely device related. If this is the first time you have ever used Retrospect (in other words, if you just installed Retrospect and have never before scanned for devices successfully with Retrospect), please contact Dantz Technical Support for assistance.

 

 

 

If Retrospect was working fine previously, and you just recently added a device or changed your configuration, this may be the cause of the problem. If you added a device, try removing it, to see if this makes the error go away. (Remember to restart the computer between tests.) If this solves the problem, look up your new device in the Dantz hardware database (www.dantz.com/hardware) to see if there are any special notes about using that device with Retrospect. If you recently changed your configuration, verify that the changes you made were made correctly, and/or consider reversing the changes as a test, to see if that clears up the problem.

 

 

 

Check for loose cables, and/or incorrectly configured hardware. Specifically, if you have changed an ATAPI device configuration, verify that you have the device DIP switches set properly for master and slave devices. If you are using a SCSI device, make sure you have each device set to a unique ID, with proper termination on the entire bus. Refer to the Retrospect User's Guide for detailed information regarding SCSI termination. Make sure you have the latest recommended drivers installed for your SCSI card by checking the manufacturer's web site. If you are using USB or IEEE 1394/FireWire devices, try removing one or more devices to simplify your bus, to see if this resolves the problem. If you are unable to determine the cause of the error, please contact Dantz Technical Support for assistance.

 

 

 

Scanning a source volume in a backup or duplicate operations

 

 

 

While very rare, Retrospect can report one of these errors during scanning of a source volume. If this occurs, check the disk for corruption using the built in Windows disk checking utility, or another disk utility program. If the problem is repeatable, it may be caused by file or folder names or structures on the hard disk. You may be able to narrow down the problem by defining a Subvolume in Retrospect for each top level folder on the hard disk, and then scanning each one at a time, to determine the folder that causes the problem. Then you may be able to rename files or folders to avoid the problem.

 

 

 

 

 

Matching during a backup

 

 

 

After scanning a source for backup, Retrospect matches the files found on that source with the contents of the backup set you are backing up to. If a backup set catalog file (typically stored on your hard disk) is corrupt, you may get an error during matching. If you do, verify that the error occurs at the same place by repeating the operation. If it does, likely the catalog file is corrupt.

 

 

 

A quick way to test if a catalog file is corrupt is to perform a searching restore, entering any file name in the space when prompted, to force Retrospect to load and search every single session in the backup set. If the backup set catalog is corrupt, you may get an error similar to -641 (chunk checksum didn't match) or -2241 (catalog invalid/damaged). If this happens, your backup set catalog is corrupt. This does not affect the data stored in your backup set media.

 

 

 

The best way to recover from this is to rebuild the backup set catalog from the media, using Tools>Repair in Retrospect. Start with the last member of the backup set that you were using at the time of the error. The rebuild may take a while. If you have the backup set catalog backed up in another set, you may restore the file, and then do an "update existing" operation in Tools>Repair, which is quicker than a complete rebuild.

 

 

 

If this happens once, you may never know how the catalog became corrupt. If this happens chronically, review the notes below under Chronic Problems for tips.

 

 

 

Starting a backup/Updating catalog...

 

 

 

Right after scanning and matching during a backup, Retrospect writes the source "Snapshot" to the backup set catalog. You may get an error at that time that includes "can't save Snapshot". If you do, follow the tips in the note above for "Matching During a Backup."

 

 

 

 

 

Matching during a restore

 

 

 

If you get the error during restore preparation during the Matching phase, you likely have a corrupt catalog. Follow the tips in the note above for "Matching During a Backup."

 

 

 

Preparing for Disaster Recovery

 

 

 

If you get the error during disaster recovery preparation, it may be worth trying to prepare using a different backup set. Whether or not this works, we recommend that you contact Dantz Technical Support for assistance.

 

 

 

 

 

Chronic Chunk or Catalog Problems

 

 

 

If you encounter chronic chunk or catalog related problems, you will need to determine and eliminate the cause. The errors may include but are not limited to:

 

 

 

-641 chunk checksum didn't match

 

-642 chunk file map missing/damaged

 

-643 not a chunk file or badly damaged

 

-644 chunk file damaged during access

 

-645 chunk file damaged during save

 

-646 add resource failed

 

-2241 catalog invalid/damaged

 

-2243 catalog version incorrect

 

 

 

First, determine if the errors are occurring with many catalog files, or only with one. If only with one, rebuild the catalog as noted above in "Matching During a Backup", or simply start a new backup set. If the problems affect more than one backup set, you may have a hardware or system configuration problem that is causing repeated corruption of the backup set catalogs stored on your hard disk. We have seen these problems caused by specific failing hard disk.

 

 

 

Try running a surface disk check using Window's Scan Disk utility or another third party disk checking utility to verify that there are no bad blocks on the hard disk.

 

 

 

Try storing your catalog files on a different hard disk. We have seen these errors caused by an unspecified hardware problem.

 

 

 

Verify that you are using the latest or the recommended version of disk or interface driver for the hard disk you are using. For many systems, you should simply be using the hard disk and interface drivers supplied by Windows, but with SCSI, USB, high end ATAPI, and IEEE 1394/FireWire disks you may want to check for updated drivers on the drive or interface vendors' web sites.

 

 

 

Try installing and using Retrospect on a different computer. If the problems go away, something was set up incorrectly in the original computer's hardware or system software that caused regular corruption of data. Regardless of whether or not you are seeing problems with other applications or even with Windows on the original computer, if moving Retrospect solves the problem, then something was not working properly on the original computer. You may not be able to determine the cause, given how complex computers are.

 

 

 

If you are unable to resolve the problems, please contact Dantz Technical Support for further assistance.

 

 

 

 

 

Getting Help from Dantz Technical Support

 

 

 

Should you be unable to solve an internal consistency error problem on your own, Dantz Technical Support will be glad to help you after a support incident is opened.

 

 

 

 

 

List of Known Errors and Workarounds

 

 

 

The following is a partial list of assert errors and their resolutions:

 

 

 

module.cpp-646, This error may occur when trying to use the erase all option in Retrospect 5.0. Upgrade to the latest version of Retrospect for Windows.

 

 

 

droxy.cpp-1357, This error may occur when quitting Retrospect 5.0. Upgrade to the latest version of Retrospect.

 

 

 

scsitools.cpp-2911, This error may be corrected by updating your SCSI card drivers and firmware to the latest version available from the card vendor.

 

 

 

module.cpp-457, This error in Retrospect 5.5 is caused by using keyboard shortcuts for Add (alt-A) or Modify (alt-M) during Disaster Recovery. Use your mouse to click the necessary buttons. The problem is fixed in the latest version.

 

 

 

statefile.cpp-150, This error in Retrospect 5.5 or earlier can usually be avoided by turning off backup of NTFS security information. This option can be found under Options for your script or backup operation. The problem is fixed in the latest version.

 

 

 

tstring.cpp-550, This error occurs in Retrospect 5.5.144 if you attempt to duplicate from one source to a destination both on the same client computer. This is not supported in Retrospect. Choose a different volume for the source or destination. The latest version of Retrospect does not assert, but instead properly reports that this is an unsupported operation.

 

 

 

tmemory.cpp-583, Upgrade to Retrospect 5.6 or later to avoid this error.

 

 

 

memutil.cpp-198, Upgrade to Retrospect 5.6 or later to avoid this error.

 

 

 

drwizard.cpp-1620, Upgrade to Retrospect 5.6 or later to avoid this error.

 

 

 

scsitoolsNTPT.cpp-1016, Upgrade to Retrospect 5.6 or later to avoid this error.

 

 

 

module.cpp-254, Upgrade to Retrospect 5.6 or later to avoid this error.

 

 

 

isox.cpp-692, upgrade to Retrospect 5.6 or later to avoid this error.

 

 

Link to comment
Share on other sites

re:

 

=====================

 

"If the problem is repeatable, it may be caused by file or folder names or structures on the hard disk. You may be able to narrow down the problem by defining a Subvolume in Retrospect for each top level folder on the hard disk, and then scanning each one at a time, to determine the folder that causes the problem. Then you may be able to rename files or folders to avoid the problem."

 

=====================

 

 

 

Is that to say that even though something is named legally as far as Windows is concerned, Retrospect may not be able to handle it?

 

 

 

If true, sounds ominious in the context of a many-computer environment...

Link to comment
Share on other sites

In reply to:

Is that to say that even though something is named legally as far as Windows is concerned, Retrospect may not be able to handle it?


 

 

 

Not exactly, but close. There may be corruption in a directory that is not being detected by Windows. If you can isolate the problem to a specific folder - try duplicating the folder and backing up the copy, or copy the contents to a new folder and try backing up the new folder.

 

 

 

We've also seen files that are on a Windows machine that don't follow Windows naming convention - and these files can't be backed up properly in many cases. In some cases, files are saved through shared network volumes and given names allowable on the client machine.

Link to comment
Share on other sites

Amy, thanks for your response. I have now worked through suggestions as much as I can but still need some help. Part of the problem may be identifying the precise operation where assertion error arises. Also, the problem has occurred on 2 of 3 backup sets but not so far on the 3rd.

 

 

 

The launching & scanning for devices operations seem ok. The problem appears somewhere between what response describes as "matching" & "updating catalog w/ snapshot". In manual backup, screen sequence seems to be that it compares the new hard disk files to tape (scanning has correct # hard disk files, and matching shows reasonable # new files to update) and then it begins "locating ..." but runs without noticeable progress or end. Pause or stop does not stop tape running or locating screen; control-alt-delete to end task stops program, ususally w/ assertion wind.cpp-1161 error messae.

 

 

 

In automatic script mode, screens are a little different; scanned seems to get all hard disk files, matched shows same # additional MB added; then it goes into Locating... w/o progress and same system lock up and assertion message when end task.

 

 

 

I did the suggested catalog problem find file test suggested (restore>find files>select backup set b>retrieve files&folders>name of test file). It correctly found the 1 test file and save it into new C:\backup folder.

 

 

 

I also tried rebuild catalog; but it ran through a large number of files before seizing up near the end of total number of files. I did this several times and the screen would lock up and blacks out and requires physical reboot (CAD end task won't appear or work).

 

 

 

After that I tried to update what appeared to be a partial new catalog file, but got an error messsage saying it was not the catalog I had selected. Clicking into more choices showed two backup set B's, one w/o the date (wrong one per message) and one with current date. I tried to update the current date one but got an out of synch message. When I followed the out of synch repair instructions (tools>repair catalog> update existing file), it ran a long lime then gave error message "execution incomplete" see log for details; this showed error 102 trouble communicating twice and error 205 lost access.

 

 

 

Other information for you is how this works on different back up sets. I use two groups of three tapes: A B & C plus D E F. Generally I run abc until full, then switch to def and then erase and start over. Here, the problem started w/ B and then was same when I tried C. Later I tried A and it worked (incremental back up). When I could not get B & C to work or catalog rebuild to work, I erased B & C and started them over. They each worked fine for full back up but problems started again with B update. I have also fully erased and back up DEF w/o problem, but have not tried to increment them.

 

 

 

Thanks for your patience and help. The system has worked fine up to this problem.

 

 

 

 

Link to comment
Share on other sites

As follow up to my last inquiry, here is assert_log.utx copied and pasted from last backup set b problem as log note said to send this to dantz tech. thanks again.

 

 

 

 

 

 

 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

 

 

 

OS: Windows Me version 4.90 (build 3000),

 

Application: C:\PROGRAM FILES\DANTZ\RETROSPECT\RETROSPECT.EXE, version 6.0.206

 

Exception occurred on 12/26/2002 at 6:21:00 PM

 

Error info: Assertion failure at "wind.cpp-1161"

 

Exception code: E0000000 ASSERTION

 

Fault address: 7C01BA05 0001:0001AA05 MSVCR70.DLL

 

 

 

 

 

Thread ID: FFFEBBE1, Name: RetroFrameThread

 

 

 

EAX:0254DEBC CS:0177 EIP:7C01BA05 EFlags:00000202

 

EBX:0254E998 SS:017F ESP:0254DEA0 EBP: 0254DEC8

 

ECX:00000000 DS:017F ESI:7C03FDB4 FS: 1B27

 

EDX:6007367C ES:017F EDI:0254DEC8 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

MSVCR70.DLL 0001:0001AA05 0 0 0254E08C 0254E108 0254E998 60073690 0254DED8 0254DB50

 

BEDROCK.DLL DebugHandler::Throw +53 E0000000 1 1 0254DF2C 0254E02C 60044E0D E0000000 1

 

BEDROCK.DLL assertLog +1B E0000000 1 0254DF2C 'essA' 'oitr' 'af n' 'ruli' 'ta e'

 

BEDROCK.DLL Debug +59 'ahH<' 00000489 017179D0 0 0254E058 6166A31B 017179B0 0254E16C

 

UIMESON.DLL windGetDC +59 017179B0 0254E16C 017179D0 0254E0D0 60609BE1 017179B0 0254E16C 0254E16C

 

UIMESON.DLL windCreateGraf +31 017179B0 0254E16C 0254E16C 0254E168 0254E16C 0254E16C 017179B0 00000E68

 

MESON.DLL ModuleData::send +652 017179B0 'WCGr' 0254E16C 0254E16C 0254E168 0254E16C 0254E16C 017179B0

 

UIMESON.DLL TGrafFact::Set +121 01733B7C 0 0 1 0254E168 0254E1C8 'agJ5' 1

 

UIMESON.DLL TGrafFact::TGrafFact +63 01733B7C 0 0 1 01733B9C 0254E16C 0 -1

 

UIMESON.DLL itemEraseRgn +63 01733B7C 0 0254E268 01733B9C 00000B8C 0 0254E8A4 6167488A

 

MESON.DLL ModuleData::send +652 01733B7C 'IErR' 0 0254E268 01733B9C 00000B8C 0 0254E8A4

 

UIMESON.DLL itemErase +66 01733B7C 0 01733BF8 1 3 0254E38C 60609BE1 01733B7C

 

MESON.DLL ModuleData::send +652 01733B7C 'IErs' 0 01733BF8 1 3 0254E38C 60609BE1

 

UIMESON.DLL statBarTextSet +96 01733B7C 'msg3' 0254E66C 0171C91C 0254E420 60609BE1 0171C880 3

 

MESON.DLL ModuleData::send +652 01733B7C 'SBTS' 'msg3' 0254E66C 0171C91C 0254E420 60609BE1 0171C880

 

UIPROD.DLL refpSetStatusBarText +39 0171C880 3 0254E66C 0254E440 0254E440 0000000F 0 0

 

MESON.DLL ModuleData::send +652 0171C880 'mFSx' 3 0254E66C 0254E440 0254E440 0000000F 0

 

UIPROD.DLL refpSetStatusBarTime +12C 0171C880 01734304 0254E97C BFF62317 0 00000113 00000340 00142527

 

MESON.DLL ModuleData::send +652 0171C880 'mFSm' 01734304 0254E97C BFF62317 0 00000113 00000340

 

MESON.DLL timerProc +78 0 00000113 00000340 00142527 1B37899C EAA41B37 89F88A04 00030007

 

KERNEL32.DLL 0001:00001317 BFF43BCD 0 00000113 00000340 00142527 1B37899C EAA41B37 89F88A04

 

 

 

 

 

Thread ID: FFFBDE7D, Name: Immediate execution thread

 

 

 

EAX:002A005C CS:0177 EIP:BFF8A127 EFlags:00000246

 

EBX:81D4E3C0 SS:017F ESP:02798A10 EBP: 02798AFC

 

ECX:F18ACC60 DS:017F ESI:00000000 FS: 1D67

 

EDX:BFFBB490 ES:017F EDI:F18AB750 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:00021127 5 004261D8 0 02799405 5 00425894 02798B40 60143E39

 

MESON.DLL ScsiTrans +EE 004261D8 0 0000000A 00426274 004258AC 0 004261D8 02798B7C

 

DEVICES.DLL dsixTrans +2B6 00425894 1 0000000A 0 0 001B7740 0 004263B0

 

DEVICES.DLL dsixBeginLocate +32F 00425894 0 0 0 BFF619B8 02798BD8 02798DB4 BFF6186D

 

DEVICES.DLL dsixLocEngine +3F6 00425894 0 0279925C 0279925C 0000000B 0 0 000004E4

 

DEVICES.DLL dsixLocate +15C 00425894 000473EF 0000005D 0 00046BEE 00426274 004258AC 02799530

 

DEVICES.DLL dsixUSeek +8B 00425894 000473EF 0000005D 00046BEE 02799D3C 02799568 6061126E 01843278

 

MESON.DLL ModuleData::send +652 00425894 'DVSk' 000473EF 0000005D 00046BEE 02799D3C 02799568 6061126E

 

ENGINELO.DLL xopSetDevice +198 0183A224 00425894 000473EF 0 0000005D 00046BEE 0 1

 

MESON.DLL ModuleData::send +652 0183A224 'ArSV' 00425894 000473EF 0 0000005D 00046BEE 0

 

ENGINELO.DLL arxSetDevice +123 0041F638 00046BEE 0 0 B94E006B 00000023 0279BE08 0

 

ENGINELO.DLL arxAllocate +636 0041F638 6351EA9C 0279D10C 1FEF1000 0 00000023 0 0

 

MESON.DLL ModuleData::send +652 0041F638 'arxa' 6351EA9C 0279D10C 1FEF1000 0 00000023 0

 

MESON.DLL doTask +299 'Eng1' 0 0041F638 'arxa' 0279BE04 0279BE04 0279CB58 0279CB58

 

MESON.DLL TThread::TaskSend +23 018046B4 'Eng1' 0041F638 'arxa' 6351EA9C 0279D10C 1FEF1000 0

 

ENGINELO.DLL arxTask +735 0041F638 0279E108 004B9000 'pgEx' 0279D150 60609BE1 004B8FE8 0279E108

 

MESON.DLL ModuleData::send +652 0041F638 'arxt' 0279E108 004B9000 'pgEx' 0279D150 60609BE1 004B8FE8

 

MESON.DLL doTask +299 'EnOp' 0 0041F638 'arxt' 0279D0CC 0279D0CC 1 0279D0D8

 

MESON.DLL TThread::TaskSend +23 018046B4 'EnOp' 0041F638 'arxt' 0279E108 004B9000 'pgEx' 0279D150

 

ENGINELO.DLL arxEngineBlock +66 004B8FE8 0279E108 0279EF28 0279EFA4 0279D1A8 60012786 0279D2DC 016CE738

 

MESON.DLL ModuleData::send +652 004B8FE8 'EnBk' 0279E108 0279EF28 0279EFA4 0279D1A8 60012786 0279D2DC

 

ENGINEHI.DLL extoBegin +823 01805FB4 01805FCC 0 0279F928 6062B461 01805FB4 0 01805FCC

 

MESON.DLL ModuleData::send +652 01805FB4 'ExBg' 01805FCC 0 0279F928 6062B461 01805FB4 0

 

MESON.DLL doTask +299 'ExOp' 0 01805FB4 'ExBg' 0279F468 0279F468 0279FCB0 0279F470

 

MESON.DLL TThread::TaskSend +23 018046B4 'ExOp' 01805FB4 'ExBg' 01805FCC 0 0279F928 6062B461

 

ENGINEHI.DLL execDoRun +1EE 01805FB4 0 01805FCC 01805FCC 0279F9E8 60609BE1 01805FB4 0

 

MESON.DLL doTask +21E 'EScr' 60226BB2 0 0 0279F960 0279F960 02DEFCE0 0279F970

 

MESON.DLL TThread::TaskCall +21 018046B4 'EScr' 60226BB2 01805FB4 0 01805FCC 01805FCC 0279F9E8

 

ENGINEHI.DLL execRun +33 01805FB4 0 0279FA38 0279FF20 01805FB4 0279FEC0 6062B461 0048B1C4

 

MESON.DLL ModuleData::send +652 01805FB4 'ExRu' 0 0279FA38 0279FF20 01805FB4 0279FEC0 6062B461

 

ENGINEHI.DLL execIStartThreadProc +6A 0048B1C4 1 016CCA38 00000383 01853FA8 0184B230 0254E050 60609BE1

 

MESON.DLL doTask +21E 'Task' 602282A0 0 0 0279FEF8 0279FEF8 60631D2E 0279FF64

 

MESON.DLL TThread::TaskCall +21 018046B4 'Task' 602282A0 0048B1C4 1 016CCA38 00000383 01853FA8

 

MESON.DLL modThreadRoot +14F 0254DC30 81D459F4 00000008 81D4E3C0 BFFB1B20 0279FF70 -1 0279FFBC

 

MSVCR70.DLL 0001:0000312F 00960910 81D459F4 00000008 81D4E3C0 7 0279FFA4 0000017F -1

 

KERNEL32.DLL 0002:00010391 7C0040E2 00960910 00000048 0 0 0 0 BFF76D37

 

KERNEL32.DLL 0002:0000DE3A

 

 

 

 

 

Thread ID: FFF988C1, Name: driver_thread

 

 

 

EAX:002A001C CS:0177 EIP:BFF6A3E1 EFlags:00000286

 

EBX:028BE95C SS:017F ESP:028BE904 EBP: 028BE910

 

ECX:F1473120 DS:017F ESI:00000000 FS: 1DCF

 

EDX:BFFBB490 ES:017F EDI:81D60F48 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:000013E1 895A329F 0000017F BFF6CA2D 453A4C9C -1 0 BFF8470D 453A4C9C

 

KERNEL32.DLL 0002:0001A1C9 028BEF48 BFF6186D 895A329F 0 22AF895A 0000028B 02020000 0

 

 

 

 

 

Thread ID: FFF99829, Name: driver_thread

 

 

 

EAX:002A001C CS:0177 EIP:BFF6A3E1 EFlags:00000282

 

EBX:0267E95C SS:017F ESP:0267E904 EBP: 0267E910

 

ECX:EE6585A0 DS:017F ESI:00000000 FS: 1DE7

 

EDX:BFFBB490 ES:017F EDI:81D61FA0 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:000013E1 895A357F 0000017F BFF6CA2D 453A4DD0 -1 0 BFF8470D 453A4DD0

 

KERNEL32.DLL 0002:0001A1C9 0267EF48 BFF6186D 895A357F 0 35F7895A 00000267 02020000 0

 

 

 

 

 

Thread ID: FFFEB535, Name: driver_thread

 

 

 

EAX:002A005C CS:0177 EIP:BFF8A127 EFlags:00000246

 

EBX:0128E974 SS:017F ESP:0128E868 EBP: 0128E8B4

 

ECX:C1BC0750 DS:017F ESI:00000000 FS: 1D6F

 

EDX:BFFBB490 ES:017F EDI:F1492FD0 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:00021127 00425894 01280000 000089B4 895A1D7F -1 0128EA64 00425894 004240E4

 

MESON.DLL ModuleData::send +430 00425894 'Timr' 0128F9EC 0128E958 BFF62317 0 00000113 000003C2

 

MESON.DLL timerProc +78 0 00000113 000003C2 00061EB1 1DAF8978 EA801DAF 89D489E0 00030007

 

KERNEL32.DLL 0001:00001317 BFF43BCD 0 00000113 000003C2 00061EB1 1DAF8978 EA801DAF 89D489E0

 

 

 

 

 

Thread ID: FFFE3BFD, Name: Volume tracker thread

 

 

 

EAX:002A001C CS:0177 EIP:BFF6A3E1 EFlags:00000286

 

EBX:0242E984 SS:017F ESP:0242E92C EBP: 0242E938

 

ECX:C1BBDB70 DS:017F ESI:00000000 FS: 15B7

 

EDX:BFFBB490 ES:017F EDI:81D1BC74 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:000013E1 89821A7F 0000017F BFF6CA2D 453A4D8C -1 0 BFF8470D 453A4D8C

 

KERNEL32.DLL 0002:0001A1C9 0242EF70 BFF6186D 89821A7F 0 18478982 00000242 02020000 0

 

 

 

 

 

Thread ID: FFFA75DD, Name: Controller thread

 

 

 

EAX:002A001C CS:0177 EIP:BFF6A3E1 EFlags:00000286

 

EBX:0230E748 SS:017F ESP:0230E6F0 EBP: 0230E6FC

 

ECX:F1489570 DS:017F ESI:00000000 FS: 33C7

 

EDX:BFFBB490 ES:017F EDI:81D5F254 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:000013E1 874633CF 0000017F BFF6CA2D 453A4CB0 -1 0 BFF8470D 453A4CB0

 

KERNEL32.DLL 0002:0001A1C9 0230ED34 BFF6186D 874633CF 0 1B7F8746 00000230 02020000 0

 

 

 

 

 

Thread ID: FFFA0D89, Name: Quit handler thread

 

 

 

EAX:002A001C CS:0177 EIP:BFF6A3E1 EFlags:00000282

 

EBX:014CE2D4 SS:017F ESP:014CE27C EBP: 014CE288

 

ECX:F1471DF0 DS:017F ESI:00000000 FS: 32FF

 

EDX:BFFBB490 ES:017F EDI:81D58A00 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:000013E1 82D23307 0000017F BFF6CA2D 453A4CB4 -1 0 BFF8470D 453A4CB4

 

KERNEL32.DLL 0002:0001A1C9 014CE8C0 BFF6186D 82D23307 0 331782D2 0000014C 02020000 0

 

 

 

 

 

Thread ID: FFFA0151, Name: Server thread

 

 

 

EAX:002A001C CS:0177 EIP:BFF6A3E1 EFlags:00000282

 

EBX:013AE980 SS:017F ESP:013AE928 EBP: 013AE934

 

ECX:F1471B40 DS:017F ESI:00000000 FS: 3287

 

EDX:BFFBB490 ES:017F EDI:81D586D8 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:000013E1 897E32CF 0000017F BFF6CA2D 453A4CB8 -1 0 BFF8470D 453A4CB8

 

KERNEL32.DLL 0002:0001A1C9 013AEF6C BFF6186D 897E32CF 0 32DF897E 0000013A 02020000 0

 

 

 

 

 

Thread ID: FFFB61A9, Name: Main thread

 

 

 

EAX:002A001C CS:0177 EIP:BFF6A3E1 EFlags:00000282

 

EBX:0062DD18 SS:017F ESP:0062DCC0 EBP: 0062DCCC

 

ECX:F146FD40 DS:017F ESI:00000000 FS: 27E7

 

EDX:BFFBB490 ES:017F EDI:81D4E620 GS: 0000

 

 

 

 

 

Module Fn (symbol or seg:offset in DLL) Args

 

=============== ================================= =======================================================================

 

KERNEL32.DLL 0002:000013E1 8D162A67 0000017F BFF6CA2D 'E:LL' -1 0 BFF8470D 'E:LL'

 

KERNEL32.DLL 0002:0001A1C9 0062E304 BFF6186D 8D162A67 0 34678D16 00000062 02020000 0

 

 

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...