社区
数据库
帖子详情
连接SQL错误:Invalid Pointer
kedy211
2004-04-21 08:11:23
这个错误是怎么回事呀?
我应该怎么解决呢?
...全文
208
6
打赏
收藏
连接SQL错误:Invalid Pointer
这个错误是怎么回事呀? 我应该怎么解决呢?
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
6 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
kedy211
2004-04-21
打赏
举报
回复
可是我用sa也不行呀。
我更改了用户密码后是不是要重启SQL呢?
loseme915
2004-04-21
打赏
举报
回复
看看你的帐号有没有付给权限吧!!
kedy211
2004-04-21
打赏
举报
回复
不过现在的错误是Unspecified Error
kedy211
2004-04-21
打赏
举报
回复
_ConnectionPtr m_pMyConnect=NULL;
HRESULT hr=m_pMyConnect.CreateInstance(__uuidof(Connection));
if(FAILED(hr))
{
AfxMessageBox("Hr Error!");
return FALSE;
}
_bstr_t strConnect="Provider=SQLOLEDB; Server=local;"
"Database=CFAS_FP; uid=fpadmin; pwd=ncust;";
//connecting to the database server now:
try
{
m_pMyConnect->Open(strConnect,"fpadmin","ncust",NULL);
}
catch (_com_error e)
{
CString errormessage;
errormessage.Format("连接数据库错误!\r\n错误信息:%s",e.ErrorMessage());
AfxMessageBox(errormessage);
}
这样也有问题!晕!
kedy211
2004-04-21
打赏
举报
回复
AfxOleInit();
_ConnectionPtr m_pConn;
CString m_sConn="Provider=SQLOLEDB.1;Data Source=127.0.0.1;Initial Catalog=CFAS_FP"; m_pConn.CreateInstance("ADODB.Connection");
try
{
HRESULT hr=m_pConn->Open((_bstr_t)m_sConn,"fpadmin","ncust",adModeUnknown);
if (FAILED(hr))
{
AfxMessageBox("HR错误!");
return FALSE;
}
}
catch(_com_error e)
{
CString errormessage;
errormessage.Format("连接数据库失败!\r\n错误信息:%s",e.ErrorMessage());
AfxMessageBox(errormessage);//ÏÔʾ´íÎóÐÅÏ¢
}
Pipi0714
2004-04-21
打赏
举报
回复
贴出你的源代码
微软内部资料-
SQL
性能优化2
Contents Module Ov
er
view 1 Lesson 1: Memory 3 Lesson 2: I/O 73 Lesson 3: CPU 111 Module 3: Troubleshooting S
er
v
er
P
er
formance Module Ov
er
view Troubleshooting s
er
v
er
p
er
formance-based support calls requires product knowledge, good communication skills, and a proven troubleshooting methodology. In this module we will discuss Microsoft®
SQL
S
er
v
er
™ int
er
action with the op
er
ating system and methodology of troubleshooting s
er
v
er
-based problems. At the end of this module, you will be able to: Define the common t
er
ms associated the memory, I/O, and CPU subsystems. Describe how
SQL
S
er
v
er
lev
er
ages the Microsoft Windows® op
er
ating system facilities including memory, I/O, and threading. Define common
SQL
S
er
v
er
memory, I/O, and processor t
er
ms. Gen
er
ate a hypothesis based on p
er
formance count
er
s captured by System Monitor. For each hypothesis gen
er
ated, identify at least two oth
er
non-System Monitor pieces of information that would help to confirm or reject your hypothesis. Identify at least five count
er
s for each subsystem that are key to und
er
standing the p
er
formance of that subsystem. Identify three common myths associated with the memory, I/O, or CPU subsystems. Lesson 1: Memory What You Will Learn Aft
er
completing this lesson, you will be able to: Define common t
er
ms used when describing memory. Give examples of each memory concept and how it applies to
SQL
S
er
v
er
. Describe how
SQL
S
er
v
er
us
er
and manages its memory. List the primary configuration options that affect memory. Describe how configuration options affect memory usage. Describe the effect on the I/O subsystem when memory runs low. List at least two memory myths and why they are not true. Recommended Reading
SQL
S
er
v
er
7.0 P
er
formance Tuning Technical Ref
er
ence, Microsoft Press Windows 2000 Resource Kit companion CD-ROM documentation. Chapt
er
15: Ov
er
view of P
er
formance Monitoring Inside Microsoft Windows 2000, Third Edition, David A. Solomon and Mark E. Russinovich Windows 2000 S
er
v
er
Op
er
ations Guide, Storage, File Systems, and Printing; Chapt
er
s: Evaluating Memory and Cache Usage Advanced Windows, 4th Edition, Jeffrey Richt
er
, Microsoft Press Related Web Sites http://ntp
er
formance/ Memory Definitions Memory Definitions Before we look at how
SQL
S
er
v
er
uses and manages its memory, we need to ensure a full und
er
standing of the more common memory related t
er
ms. The following definitions will help you und
er
stand how
SQL
S
er
v
er
int
er
acts with the op
er
ating system when allocating and using memory. Virtual Address Space A set of memory addresses that are mapped to physical memory addresses by the system. In a 32-bit op
er
ation system, th
er
e is normally a linear array of 2^32 addresses representing 4,294,967,269 byte addresses. Physical Memory A s
er
ies of physical locations, with unique addresses, that can be used to store instructions or data. AWE – Address Windowing Extensions A 32-bit process is normally limited to addressing 2 gigabytes (GB) of memory, or 3 GB if the system was booted using the /3G boot switch even if th
er
e is more physical memory available. By lev
er
aging the Address Windowing Extensions API, an application can create a fixed-size window into the additional physical memory. This allows a process to access any portion of the physical memory by mapping it into the applications window. When used in combination with Intel’s Physical Addressing Extensions (PAE) on Windows 2000, an AWE enabled application can support up to 64 GB of memory Res
er
ved Memory Pages in a processes address space are free, res
er
ved or committed. Res
er
ving memory address space is a way to res
er
ve a range of virtual addresses for lat
er
use. If you attempt to access a res
er
ved address that has not yet been committed (backed by memory or disk) you will cause an access violation. Committed Memory Committed pages are those pages that when accessed in the end translate to pages in memory. Those pages may howev
er
have to be faulted in from a page file or memory mapped file. Backing Store Backing store is the physical representation of a memory address. Page Fault (Soft/Hard) A ref
er
ence to an
invalid
page (a page that is not in your working set) is ref
er
red to as a page fault. Assuming the page ref
er
ence does not result in an access violation, a page fault can be eith
er
hard or soft. A hard page fault results in a read from disk, eith
er
a page file or memory-mapped file. A soft page fault is resolved from one of the modified, standby, free or z
er
o page transition lists. Paging is represented by a numb
er
of count
er
s including page faults/sec, page input/sec and page output/sec. Page faults/sec include soft and hard page faults wh
er
e as the page input/output count
er
s represent hard page faults. Unfortunately, all of these count
er
s include file system cache activity. For more information, see also…Inside Windows 2000,Third Edition, pp. 443-451. Private Bytes Private non-shared committed address space Working Set The subset of processes virtual pages that is resident in physical memory. For more information, see also… Inside Windows 2000,Third Edition, p. 455. System Working Set Like a process, the system has a working set. Five diff
er
ent types of pages represent the system’s working set: system cache; paged pool; pageable code and data in the k
er
nel; page-able code and data in device driv
er
s; and system mapped views. The system working set is represented by the count
er
Memory: cache bytes. System working set paging activity can be viewed by monitoring the Memory: Cache Faults/sec count
er
. For more information, see also… Inside Windows 2000,Third Edition, p. 463. System Cache The Windows 2000 cache manag
er
provides data caching for both local and network file system driv
er
s. By caching virtual blocks, the cache manag
er
can reduce disk I/O and provide intelligent read ahead. Represented by Memory:Cache Resident bytes. For more information, see also… Inside Windows 2000,Third Edition, pp. 654-659. Non Paged Pool Range of addresses guaranteed to be resident in physical memory. As such, non-paged pool can be accessed at any time without incurring a page fault. Because device driv
er
s op
er
ate at DPC/dispatch level (cov
er
ed in lesson 2), and page faults are not allowed at this level or above, most device driv
er
s use non-paged pool to assure that they do not incur a page fault. Represented by Memory: Pool Nonpaged Bytes, typically between 3-30 megabytes (MB) in size. Note The pool is, in effect, a common area of memory shared by all processes. One of the most common uses of non-paged pool is the storage of object handles. For more information regarding “maximums,” see also… Inside Windows 2000,Third Edition, pp. 403-404 Paged Pool Range of address that can be paged in and out of physical memory. Typically used by driv
er
s who need memory but do not need to access that memory from DPC/dispatch of above int
er
rupt level. Represented by Memory: Pool Paged Bytes and Memory:Pool Paged Resident Bytes. Typically between 10-30MB + size of Registry. For more information regarding “limits,” see also… Inside Windows 2000,Third Edition, pp. 403-404. Stack Each thread has two stacks, one for k
er
nel mode and one for us
er
mode. A stack is an area of memory in which program procedure or function call addresses and paramet
er
s are temporarily stored. In Process To run in the same address space. In-process s
er
v
er
s are loaded in the client’s address space because they are implemented as DLLs. The main advantage of running in-process is that the system usually does not need to p
er
form a context switch. The disadvantage to running in-process is that DLL has access to the process address space and can potentially cause problems. Out of Process To run outside the calling processes address space. OLEDB provid
er
s can run in-process or out of process. When running out of process, they run und
er
the context of DLLHOST.EXE. Memory Leak To res
er
ve or commit memory and unintentionally not release it when it is no long
er
being used. A process can leak resources such as process memory, pool memory, us
er
and GDI objects, handles, threads, and so on. Memory Concepts (X86 Address Space) P
er
Process Address Space Ev
er
y process has its own private virtual address space. For 32-bit processes, that address space is 4 GB, based on a 32-bit
point
er
. Each process’s virtual address space is split into us
er
and system partitions based on the und
er
lying op
er
ating system. The diagram included at the top represents the address partitioning for the 32-bit v
er
sion of Windows 2000. Typically, the process address space is evenly divided into two 2-GB regions. Each process has access to 2 GB of the 4 GB address space. The upp
er
2 GB of address space is res
er
ved for the system. The us
er
address space is wh
er
e application code, global variables, p
er
-thread stacks, and DLL code would reside. The system address space is wh
er
e the k
er
nel, executive, HAL, boot driv
er
s, page tables, pool, and system cache reside. For specific information regarding address space layout, ref
er
to Inside Microsoft Windows 2000 Third Edition pages 417-428 by Microsoft Press. Access Modes Each virtual memory address is tagged as to what access mode the processor must be running in. System space can only be accessed while in k
er
nel mode, while us
er
space is accessible in us
er
mode. This protects system space from being tamp
er
ed with by us
er
mode code. Shared System Space Although ev
er
y process has its own private memory space, k
er
nel mode code and driv
er
s share system space. Windows 2000 does not provide any protection to private memory being use by components running in k
er
nel mode. As such, it is v
er
y important to ensure components running in k
er
nel mode are thoroughly tested. 3-GB Address Space 3-GB Address Space Although 2 GB of address space may seem like a large amount of memory, application such as
SQL
S
er
v
er
could lev
er
age more memory if it w
er
e available. The boot.ini option /3GB was created for those cases wh
er
e systems actually support great
er
than 2 GB of physical memory and an application can make use of it This capability allows memory intensive applications running on Windows 2000 Advanced S
er
v
er
to use up to 50 p
er
cent more virtual memory on Intel-based comput
er
s. Application memory tuning provides more of the comput
er
's virtual memory to applications by providing less virtual memory to the op
er
ating system. Although a system having less than 2 GB of physical memory can be booted using the /3G switch, in most cases this is ill-advised. If you restart with the 3 GB switch, also known as 4-Gig Tuning, the amount of non-paged pool is reduced to 128 MB from 256 MB. For a process to access 3 GB of address space, the executable image must have been linked with the /LARGEADDRESSAWARE flag or modified using Imagecfg.exe. It should be
point
ed out that
SQL
S
er
v
er
was linked using the /LAREGEADDRESSAWARE flag and can lev
er
age 3 GB when enabled. Note Even though you can boot Windows 2000 Professional or Windows 2000 S
er
v
er
with the /3GB boot option, us
er
s processes are still limited to 2 GB of address space even if the IMAGE_FILE_LARGE_ADDRESS_AWARE flag is set in the image. The only thing accomplished by using the /3G option on these system is the reduction in the amount of address space available to the system (ISW2K Pg. 418). Important If you use /3GB in conjunction with AWE/PAE you are limited to 16 GB of memory. For more information, see the following Knowledge Base articles: Q171793 Information on Application Use of 4GT RAM Tuning Q126402 PagedPoolSize and NonPagedPoolSize Values in Windows NT Q247904 How to Configure Paged Pool and System PTE Memory Areas Q274598 W2K Does Not Enable Complete Memory Dumps Between 2 & 4 GB AWE Memory Layout AWE Memory Usually, the op
er
ation system is limited to 4 GB of physical memory. Howev
er
, by lev
er
aging PAE, Windows 2000 Advanced S
er
v
er
can support up to 8 GB of memory, and Data Cent
er
64 GB of memory. Howev
er
, as stated previously, each 32-bit process normally has access to only 2 GB of address space, or 3 GB if the system was booted with the /3-GB option. To allow processes to allocate more physical memory than can be represented in the 2GB of address space, Microsoft created the Address Windows Extensions (AWE). These extensions allow for the allocation and use of up to the amount of physical memory supported by the op
er
ating system. By lev
er
aging the Address Windowing Extensions API, an application can create a fixed-size window into the physical memory. This allows a process to access any portion of the physical memory by mapping regions of physical memory in and out of the applications window. The allocation and use of AWE memory is accomplished by Creating a window via VirtualAlloc using the MEM_PHYSICAL option Allocating the physical pages through AllocateUs
er
PhysicalPages Mapping the RAM pages to the window using MapUs
er
PhysicalPages Note
SQL
S
er
v
er
7.0 supports a feature called extended memory in Windows NT® 4 Ent
er
prise Edition by using a PSE36 driv
er
. Currently th
er
e are no PSE driv
er
s for Windows 2000. The pref
er
red method of accessing extended memory is via the Physical Addressing Extensions using AWE. The AWE mapping feature is much more efficient than the old
er
process of coping buff
er
s from extended memory into the process address space. Unfortunately,
SQL
S
er
v
er
7.0 cannot lev
er
age PAE/AWE. Because th
er
e are currently no PSE36 driv
er
s for Windows 2000 this means
SQL
S
er
v
er
7.0 cannot support more than 3GB of memory on Windows 2000. Ref
er
to KB article Q278466. AWE restrictions The process must have Lock Pages In Memory us
er
rights to use AWE Important It is important that you use Ent
er
prise Manag
er
or DMO to change the s
er
vice account. Ent
er
prise Manag
er
and DMO will grant all of the privileges and Registry and file p
er
missions needed for
SQL
S
er
v
er
. The S
er
vice Control Panel does NOT grant all the rights or p
er
missions needed to run
SQL
S
er
v
er
. Pages are not shareable or page-able Page protection is limited to read/write The same physical page cannot be mapped into two separate AWE regions, even within the same process. The use of AWE/PAE in conjunction with /3GB will limit the maximum amount of supported memory to between 12-16 GB of memory. Task manag
er
does not show the correct amount of memory allocated to AWE-enabled applications. You must use Memory Manag
er
: Total S
er
v
er
Memory. It should, howev
er
, be noted that this only shows memory in use by the buff
er
pool. Machines that have PAE enabled will not dump us
er
mode memory. If an event occurs in Us
er
Mode Memory that causes a blue screen and root cause det
er
mination is absolutely necessary, the machine must be booted with the /NOPAE switch, and with /MAXMEM set to a numb
er
appropriate for transf
er
ring dump files. With AWE enabled,
SQL
S
er
v
er
will, by default, allocate almost all memory during startup, leaving 256 MB or less free. This memory is locked and cannot be paged out. Consuming all available memory may prevent oth
er
applications or
SQL
S
er
v
er
instances from starting. Note PAE is not required to lev
er
age AWE. Howev
er
, if you have more than 4GB of physical memory you will not be able to access it unless you enable PAE. Caution It is highly recommended that you use the “max s
er
v
er
memory” option in combination with “awe enabled” to ensure some memory headroom exists for oth
er
applications or instances of
SQL
S
er
v
er
, because AWE memory cannot be shared or paged. For more information, see the following Knowledge Base articles: Q268363 Intel Physical Addressing Extensions (PAE) in Windows 2000 Q241046 Cannot Create a dump File on Comput
er
s with ov
er
4 GB RAM Q255600 Windows 2000 utilities do not display physical memory above 4GB Q274750 How to configure
SQL
S
er
v
er
memory more than 2 GB (Idea) Q266251 Memory dump stalls when PAE option is enabled (Idea) Tip The KB will return more hits if you qu
er
y on PAE rath
er
than AWE. Virtual Address Space Mapping Virtual Address Space Mapping By default Windows 2000 (on an X86 platform) uses a two-level (three-level when PAE is enabled) page table structure to translate virtual addresses to physical addresses. Each 32-bit address has three components, as shown below. When a process accesses a virtual address the system must first locate the Page Directory for the current process via regist
er
CR3 (X86). The first 10 bits of the virtual address act as an index into the Page Directory. The Page Directory Entry then
point
s to the Page Frame Numb
er
(PFN) of the appropriate Page Table. The next 10 bits of the virtual address act as an index into the Page Table to locate the appropriate page. If the page is valid, the PTE contains the PFN of the actual page in memory. If the page is not valid, the memory management fault handl
er
locates the page and attempts to make it valid. The final 12 bits act as a byte offset into the page. Note This multi-step process is expensive. This is why systems have translation look aside buff
er
s (TLB) to speed up the process. One of the reasons context switching is so expensive is the translation buff
er
s must be dumped. Thus, the first few lookups are v
er
y expensive. Ref
er
to ISW2K pages 439-440. Core System Memory Related Count
er
s Core System Memory Related Count
er
s When evaluating memory p
er
formance you are looking at a wide variety of count
er
s. The count
er
s listed h
er
e are a few of the core count
er
s that give you quick ov
er
all view of the state of memory. The two key count
er
s are Available Bytes and Committed Bytes. If Committed Bytes exceeds the amount of physical memory in the system, you can be assured that th
er
e is some level of hard page fault activity happening. The goal of a well-tuned system is to have as little hard paging as possible. If Available Bytes is below 5 MB, you should investigate why. If Available Bytes is below 4 MB, the Working Set Manag
er
will start to aggressively trim the working sets of process including the system cache. Committed Bytes Total memory, including physical and page file currently committed Commit Limit • Physical memory + page file size • Represents the total amount of memory that can be committed without expanding the page file. (Assuming page file is allowed to grow) Available Bytes Total physical memory currently available Note Available Bytes is a key indicator of the amount of memory pressure. Windows 2000 will attempt to keep this above approximately 4 MB by aggressively trimming the working sets including system cache. If this value is constantly between 3-4 MB, it is cause for investigation. One count
er
you might expect would be for total physical memory. Unfortunately, th
er
e is no specific count
er
for total physical memory. Th
er
e are howev
er
many oth
er
ways to det
er
mine total physical memory. One of the most common is by viewing the P
er
formance tab of Task Manag
er
. Page File Usage The only count
er
s that show current page file space usage are Page File:% Usage and Page File:% Peak Usage. These two count
er
s will give you an indication of the amount of space currently used in the page file. Memory P
er
formance Memory Count
er
s Th
er
e are a numb
er
of count
er
s that you need to investigate when evaluating memory p
er
formance. As stated previously, no single count
er
provides the entire picture. You will need to consid
er
many diff
er
ent count
er
s to begin to und
er
stand the true state of memory. Note The count
er
s listed are a subset of the count
er
s you should capture. *Available Bytes In gen
er
al, it is desirable to see Available Bytes above 5 MB.
SQL
S
er
v
er
s goal on Intel platforms, running Windows NT, is to assure th
er
e is approximately 5+ MB of free memory. Aft
er
Available Bytes reaches 4 MB, the Working Set Manag
er
will start to aggressively trim the working sets of process and, finally, the system cache. This is not to say that working set trimming does not happen before 4 MB, but it does become more pronounced as the numb
er
of available bytes decreases below 4 MB. Page Faults/sec Page Faults/sec represents the total numb
er
of hard and soft page faults. This value includes the System Working Set as well. Keep this in mind when evaluating the amount of paging activity in the system. Because this count
er
includes paging associated with the System Cache, a s
er
v
er
acting as a file s
er
v
er
may have a much high
er
value than a dedicated
SQL
S
er
v
er
may have. The System Working Set is cov
er
ed in depth on the next slide. Because Page Faults/sec includes soft faults, this count
er
is not as useful as Pages/sec, which represents hard page faults. Because of the associated I/O, hard page faults tend to be much more expensive. *Pages/sec Pages/sec represent the numb
er
of pages written/read from disk because of hard page faults. It is the sum of Memory: Pages Input/sec and Memory: Pages Output/sec. Because it is counted in numb
er
s of pages, it can be compared to oth
er
counts of pages, such as Memory: Page Faults/sec, without conv
er
sion. On a well-tuned system, this value should be consistently low. In and of itself, a high value for this count
er
does not necessarily indicate a problem. You will need to isolate the paging activity to det
er
mine if it is associated with in-paging, out-paging, memory mapped file activity or system cache. Any one of these activities will contribute to this count
er
. Note Paging in and of itself is not necessarily a bad thing. Paging is only “bad” when a critical process must wait for it’s pages to be in-paged, or when the amount of read/write paging is causing excessive k
er
nel time or disk I/O, thus int
er
f
er
ing with normal us
er
mode processing. Tip (Memory: Pages/sec) / (PhysicalDisk: Disk Bytes/sec * 4096) yields the approximate p
er
centage of paging to total disk I/O. Note, this is only relevant on X86 platforms with a 4 KB page size. Page Reads/sec (Hard Page Fault) Page Reads/sec is the numb
er
of times the disk was accessed to resolve hard page faults. It includes reads to satisfy faults in the file system cache (usually requested by applications) and in non-cached memory mapped files. This count
er
counts numb
er
s of read op
er
ations, without regard to the numb
er
s of pages retrieved by each op
er
ation. This count
er
displays the diff
er
ence between the values obs
er
ved in the last two samples, divided by the duration of the sample int
er
val. Page Writes/sec (Hard Page Fault) Page Writes/sec is the numb
er
of times pages w
er
e written to disk to free up space in physical memory. Pages are written to disk only if they are changed while in physical memory, so they are likely to hold data, not code. This count
er
counts write op
er
ations, without regard to the numb
er
of pages written in each op
er
ation. This count
er
displays the diff
er
ence between the values obs
er
ved in the last two samples, divided by the duration of the sample int
er
val. *Pages Input/sec (Hard Page Fault) Pages Input/sec is the numb
er
of pages read from disk to resolve hard page faults. It includes pages retrieved to satisfy faults in the file system cache and in non-cached memory mapped files. This count
er
counts numb
er
s of pages, and can be compared to oth
er
counts of pages, such as Memory:Page Faults/sec, without conv
er
sion. This count
er
displays the diff
er
ence between the values obs
er
ved in the last two samples, divided by the duration of the sample int
er
val. This is one of the key count
er
s to monitor for potential p
er
formance complaints. Because a process must wait for a read page fault this count
er
, read page faults have a direct impact on the p
er
ceived p
er
formance of a process. *Pages Output/sec (Hard Page Fault) Pages Output/sec is the numb
er
of pages written to disk to free up space in physical memory. Pages are written back to disk only if they are changed in physical memory, so they are likely to hold data, not code. A high rate of pages output might indicate a memory shortage. Windows NT writes more pages back to disk to free up space when physical memory is in short supply. This count
er
counts numb
er
s of pages, and can be compared to oth
er
counts of pages, without conv
er
sion. This count
er
displays the diff
er
ence between the values obs
er
ved in the last two samples, divided by the duration of the sample int
er
val. Like Pages Input/sec, this is one of the key count
er
s to monitor. Processes will gen
er
ally not notice write page faults unless the disk I/O begins to int
er
f
er
e with normal data op
er
ations. Demand Z
er
o Faults/Sec (Soft Page Fault) Demand Z
er
o Faults/sec is the numb
er
of page faults that require a z
er
oed page to satisfy the fault. Z
er
oed pages, pages emptied of previously stored data and filled with z
er
os, are a security feature of Windows NT. Windows NT maintains a list of z
er
oed pages to accel
er
ate this process. This count
er
counts numb
er
s of faults, without regard to the numb
er
s of pages retrieved to satisfy the fault. This count
er
displays the diff
er
ence between the values obs
er
ved in the last two samples, divided by the duration of the sample int
er
val. Transition Faults/Sec (Soft Page Fault) Transition Faults/sec is the numb
er
of page faults resolved by recov
er
ing pages that w
er
e on the modified page list, on the standby list, or being written to disk at the time of the page fault. The pages w
er
e recov
er
ed without additional disk activity. Transition faults are counted in numb
er
s of faults, without regard for the numb
er
of pages faulted in each op
er
ation. This count
er
displays the diff
er
ence between the values obs
er
ved in the last two samples, divided by the duration of the sample int
er
val. System Working Set System Working Set Like processes, the system page-able code and data are managed by a working set. For the purpose of this course, that working set is ref
er
red to as the System Working Set. This is done to diff
er
entiate the system cache portion of the working set from the entire working set. Th
er
e are five diff
er
ent types of pages that make up the System Working Set. They are: system cache; paged pool; page-able code and data in ntoskrnl.exe; page-able code, and data in device driv
er
s and system-mapped views. Unfortunately, some of the count
er
s that appear to represent the system cache actually represent the entire system working set. Wh
er
e noted system cache actually represents the entire system working set. Note The count
er
s listed are a subset of the count
er
s you should capture. *Memory: Cache Bytes (Represents Total System Working Set) Represents the total size of the System Working Set including: system cache; paged pool; pageable code and data in ntoskrnl.exe; pageable code and data in device driv
er
s; and system-mapped views. Cache Bytes is the sum of the following count
er
s: System Cache Resident Bytes, System Driv
er
Resident Bytes, System Code Resident Bytes, and Pool Paged Resident Bytes. Memory: System Cache Resident Bytes (System Cache) System Cache Resident Bytes is the numb
er
of bytes from the file system cache that are resident in physical memory. Windows 2000 Cache Manag
er
works with the memory manag
er
to provide virtual block stream and file data caching. For more information, see also…Inside Windows 2000,Third Edition, pp. 645-650 and p. 656. Memory: Pool Paged Resident Bytes Represents the physical memory consumed by Paged Pool. This count
er
should NOT be monitored by itself. You must also monitor Memory: Paged Pool. A leak in the pool may not show up in Pool paged Resident Bytes. Memory: System Driv
er
Resident Bytes Represents the physical memory consumed by driv
er
code and data. System Driv
er
Resident Bytes and System Driv
er
Total Bytes do not include code that must remain in physical memory and cannot be written to disk. Memory: System Code Resident Bytes Represents the physical memory consumed by page-able system code. System Code Resident Bytes and System Code Total Bytes do not include code that must remain in physical memory and cannot be written to disk. Working Set P
er
formance Count
er
You can measure the numb
er
of page faults in the System Working Set by monitoring the Memory: Cache Faults/sec count
er
. Contrary to the “Explain” shown in System Monitor, this count
er
measures the total amount of page faults/sec in the System Working Set, not only the System Cache. You cannot measure the p
er
formance of the System Cache using this count
er
alone. For more information, see also…Inside Windows 2000,Third Edition, p. 656. Note You will find that in gen
er
al the working set manag
er
will usually trim the working sets of normal processes prior to trimming the system working set. System Cache System Cache The Windows 2000 cache manag
er
provides a write-back cache with lazy writing and intelligent read-ahead. Files are not written to disk immediately but diff
er
ed until the cache manag
er
calls the memory manag
er
to flush the cache. This helps to reduce the total numb
er
of I/Os. Once p
er
second, the lazy writ
er
thread queues one-eighth of the dirty pages in the system cache to be written to disk. If this is not sufficient to meet the needs, the lazy writ
er
will calculate a larg
er
value. If the dirty page threshold is exceeded prior to lazy writ
er
waking, the cache manag
er
will wake the lazy writ
er
. Important It should be
point
ed out that mapped files or files opened with FILE_FLAG_NO_BUFF
ER
ING, do not participate in the System Cache. For more information regarding mapped views, see also…Inside Windows 2000,Third Edition, p. 669. For those applications that would like to lev
er
age system cache but cannot tol
er
ate write delays, the cache manag
er
supports write through op
er
ations via the FILE_FLAG_WRITE_THROUGH. On the oth
er
hand, an application can disable lazy writing by using the FILE_ATTRIBUTE_TEMPORARY. If this flag is enabled, the lazy writ
er
will not write the pages to disk unless th
er
e is a shortage of memory or the file is closed. Important Microsoft
SQL
S
er
v
er
uses both FILE_FLAG_NO_BUFF
ER
ING and FILE_FLAG_WRITE_THROUGH Tip The file system cache is not represented by a static amount of memory. The system cache can and will grow. It is not unusual to see the system cache consume a large amount of memory. Like oth
er
working sets, it is trimmed und
er
pressure but is gen
er
ally the last thing to be trimmed. System Cache P
er
formance Count
er
s The count
er
s listed are a subset of the count
er
s you should capture. Cache: Data Flushes/sec Data Flushes/sec is the rate at which the file system cache has flushed its contents to disk as the result of a request to flush or to satisfy a write-through file write request. More than one page can be transf
er
red on each flush op
er
ation. Cache: Data Flush Pages/sec Data Flush Pages/sec is the numb
er
of pages the file system cache has flushed to disk as a result of a request to flush or to satisfy a write-through file write request. Cache: Lazy Write Flushes/sec Represents the rate of lazy writes to flush the system cache p
er
second. More than one page can be transf
er
red p
er
second. Cache: Lazy Write Pages/sec Lazy Write Pages/sec is the rate at which the Lazy Writ
er
thread has written to disk. Note When looking at Memory:Cache Faults/sec, you can remove cache write activity by subtracting (Cache: Data Flush Pages/sec + Cache: Lazy Write Pages/sec). This will give you a bett
er
idea of how much oth
er
page faulting activity is associated with the oth
er
components of the System Working Set. Howev
er
, you should note that th
er
e is no easy way to remove the page faults associated with file cache read activity. For more information, see the following Knowledge Base articles: Q145952 (NT4) Event ID 26 Appears If Large File Transf
er
Fails Q163401 (NT4) How to Disable Network Redirector File Caching Q181073 (
SQL
6.5) DUMP May Cause Access Violation on Win2000 System Pool System Pool As documented earli
er
, th
er
e are two types of shared pool memory: non-paged pool and paged pool. Like private memory, pool memory is susceptible to a leak. Nonpaged Pool Miscellaneous k
er
nel code and structures, and driv
er
s that need working memory while at or above DPC/dispatch level use non-paged pool. The primary count
er
for non-paged pool is Memory: Pool Nonpaged Bytes. This count
er
will usually between 3 and 30 MB. Paged Pool Driv
er
s that do not need to access memory above DPC/Dispatch level are one of the primary us
er
s of paged pool, howev
er
any process can use paged pool by lev
er
aging the ExAllocatePool calls. Paged pool also contains the Registry and file and printing structures. The primary count
er
s for monitoring paged pool is Memory: Pool Paged Bytes. This count
er
will usually be between 10-30MB plus the size of the Registry. To det
er
mine how much of paged pool is currently resident in physical memory, monitor Memory: Pool Paged Resident Bytes. Note The paged and non-paged pools are two of the components of the System Working Set. If a suspected leak is clearly visible in the ov
er
view and not associated with a process, then it is most likely a pool leak. If the leak is not associated with
SQL
S
er
v
er
handles, OLDEB provid
er
s, XPROCS or SP_OA calls then most likely this call should be pushed to the Windows NT group. For more information, see the following Knowledge Base articles: Q265028 (MS) Pool Tags Q258793 (MS) How to Find Memory Leaks by Using Pool Bitmap Analysis Q115280 (MS) Finding Windows NT K
er
nel Mode Memory Leaks Q177415 (MS) How to Use Poolmon to Troubleshoot K
er
nel Mode Memory Leaks Q126402 PagedPoolSize and NonPagedPoolSize Values in Windows NT Q247904 How to Configure Paged Pool and System PTE Memory Areas Tip To isolate pool leaks you will need to isolate all driv
er
s and third-party processes. This should be done by disabling each s
er
vice or driv
er
one at a time and monitoring the effect. You can also monitor paged and non-paged pool through poolmon. If pool tagging has been enabled via GFLAGS, you may be able to associate the leak to a particular tag. If you suspect a particular tag, you should involve the platform support group. Process Memory Count
er
s Process _Total Limitations Although the rollup of _Total for Process: Private Bytes, Virtual Bytes, Handles and Threads, represent the key resources being used across all processes, they can be misleading when evaluating a memory leak. This is because a leak in one process may be masked by a decrease in anoth
er
process. Note The count
er
s listed are a subset of the count
er
s you should capture. Tip When analyzing memory leaks, it is often easi
er
to a build eith
er
a separate chart or report showing only one or two key count
er
s for all process. The primary count
er
used for leak analysis is private bytes, but processes can leak handles and threads just as easily. Aft
er
a suspect process is located, build a separate chart that includes all the count
er
s for that process. Individual Process Count
er
s When analyzing individual process for memory leaks you should include the count
er
s listed. Process: % Processor Time Process: Working Set (includes shared pages) Process: Virtual Bytes Process: Private Bytes Process: Page Faults/sec Process: Handle Count Process: Thread Count Process: Pool Paged Bytes Process: Pool Nonpaged Bytes Tip WINLOGON, SVCHOST, s
er
vices, or SPOOLSV are ref
er
red to as HELP
ER
processes. They provide core functionality for many op
er
ations and as such are often extended by the addition of third-party DLLs. Tlist –s may help identify what s
er
vices are running und
er
a particular help
er
. Help
er
Processes Help
er
Processes Winlogon, S
er
vices, and Spoolsv and Svchost are examples of what are ref
er
red to as HELP
ER
processes. They provide core functionality for many op
er
ations and, as such, are often extended by the addition of third-party DLLs. Running ev
er
y s
er
vice in its own process can waste system resources. Consequently, some s
er
vices run in their own processes while oth
er
s share a process with oth
er
s
er
vices. One problem with sharing a process is that a bug in one s
er
vice may cause the entire process to fail. The resource kit tool, Tlist when used with the –s qualifi
er
can help you identify what s
er
vices are running in what processes. WINLOGON Used to support GINAs. SPOOLSV SPOOLSV is responsible for printing. You will need to investigate all added printing functionality. S
er
vices S
er
vice is responsible for system s
er
vices. Svchost.exe Svchost.exe is a gen
er
ic host process name for s
er
vices that are run from dynamic-link libraries (DLLs). Th
er
e can be multiple instances of Svchost.exe running at the same time. Each Svchost.exe session can contain a grouping of s
er
vices, so that separate s
er
vices can be run depending on how and wh
er
e Svchost.exe is started. This allows for bett
er
control and debugging. The Effect of Memory on Oth
er
Components Memory Drives Ov
er
all P
er
formance Processor, cache, bus speeds, I/O, all of these resources play a roll in ov
er
all p
er
ceived p
er
formance. Without minimizing the impact of these components, it is important to
point
out that a shortage of memory can often have a larg
er
p
er
ceived impact on p
er
formance than a shortage of some oth
er
resource. On the oth
er
hand, an abundance of memory can often be lev
er
aged to mask bottlenecks. For instance, in c
er
tain environments, file system cache can significantly reduce the amount of disk I/O, potentially masking a slow I/O subsystem. Effect on I/O I/O can be driven by a numb
er
of memory consid
er
ations. Page read/faults will cause a read I/O when a page is not in memory. If the modified page list becomes too long the Modified Page Writ
er
and Mapped Page Writ
er
will need to start flushing pages causing disk writes. Howev
er
, the one event that can have the greatest impact is running low on available memory. In this case, all of the above events will become more pronounced and have a larg
er
impact on disk activity. Effect on CPU The most effective use of a processor from a process p
er
spective is to spend as much time possible executing us
er
mode code. K
er
nel mode represents processor time associated with doing work, directly or indirectly, on behalf of a thread. This includes items such as synchronization, scheduling, I/O, memory management, and so on. Although this work is essential, it takes processor cycles and the cost, in cycles, to transition between us
er
and k
er
nel mode is expensive. Because all memory management and I/O functions must be done in k
er
nel mode, it follows that the few
er
the memory resources the more cycles are going to be spent managing those resources. A direct result of low memory is that the Working Set Manag
er
, Modified Page Writ
er
and Mapped Page Writ
er
will have to use more cycles attempting to free memory. Analyzing Memory Look for Trends and Trend Relationships Troubleshooting p
er
formance is about analyzing trends and trend relationships. Establishing that some event happened is not enough. You must establish the effect of the event. For example, you note that paging activity is high at the same time that
SQL
S
er
v
er
becomes slow. These two individual facts may or may not be related. If the paging is not associated with
SQL
S
er
v
er
s working set, or the disks
SQL
is using th
er
e may be little or no cause/affect relationship. Look at Physical Memory First The first item to look at is physical memory. You need to know how much physical and page file space the system has to work with. You should then evaluate how much available memory th
er
e is. Just because the system has free memory does not mean that th
er
e is not any memory pressure. Available Bytes in combination with Pages Input/sec and Pages Output/sec can be a good indicator as to the amount of pressure. The goal in a p
er
fect world is to have as little hard paging activity as possible with available memory great
er
than 5 MB. This is not to say that paging is bad. On the contrary, paging is a v
er
y effective way to manage a limited resource. Again, we are looking for trends that we can use to establish relationships. Aft
er
evaluating physical memory, you should be able to answ
er
the following questions: How much physical memory do I have? What is the commit limit? Of that physical memory, how much has the op
er
ating system committed? Is the op
er
ating system ov
er
committing physical memory? What was the peak commit charge? How much available physical memory is th
er
e? What is the trend associated with committed and available? Review System Cache and Pool Contribution Aft
er
you und
er
stand the individual process memory usage, you need to evaluate the System Cache and Pool usage. These can and often represent a significant portion of physical memory. Be aware that System Cache can grow significantly on a file s
er
v
er
. This is usually normal. One thing to consid
er
is that the file system cache tends to be the last thing trimmed when memory becomes low. If you see abrupt decreases in System Cache Resident Bytes when Available Bytes is below 5 MB you can be assured that the system is exp
er
iencing excessive memory pressure. Paged and non-paged pool size is also important to consid
er
. An ev
er
-increasing pool should be an indicator for furth
er
research. Non-paged pool growth is usually a driv
er
issue, while paged pool could be driv
er
-related or process-related. If paged pool is steadily growing, you should investigate each process to see if th
er
e is a specific process relationship. If not you will have to use tools such as poolmon to investigate furth
er
. Review Process Memory Usage Aft
er
you und
er
stand the physical memory limitations and cache and pool contribution you need to det
er
mine what components or processes are creating the pressure on memory, if any. Be careful if you opt to chart the _Total Private Byte’s rollup for all processes. This value can be misleading in that it includes shared pages and can th
er
efore exceed the actual amount of memory being used by the processes. The _Total rollup can also mask processes that are leaking memory because oth
er
processes may be freeing memory thus creating a balance between leaked and freed memory. Identify processes that expand their working set ov
er
time for furth
er
analysis. Also, review handles and threads because both use resources and potentially can be mismanaged. Aft
er
evaluating the process resource usage, you should be able to answ
er
the following: Are any of the processes increasing their private bytes ov
er
time? Are any processes growing their working set ov
er
time? Are any processes increasing the numb
er
of threads or handles ov
er
time? Are any processes increasing their use of pool ov
er
time? Is th
er
e a direct relationship between the above named resources and total committed memory or available memory? If th
er
e is a relationship, is this normal behavior for the process in question? For example,
SQL
does not commit ‘min memory’ on startup; these pages are faulted in into the working set as needed. This is not necessarily an indication of a memory leak. If th
er
e is clearly a leak in the ov
er
view and is not identifiable in the process count
er
s it is most likely in the pool. If the leak in pool is not associated with
SQL
S
er
v
er
handles, then more often than not, it is not a
SQL
S
er
v
er
issue. Th
er
e is howev
er
the possibility that the leak could be associated with third party XPROCS, SP_OA* calls or OLDB provid
er
s. Review Paging Activity and Its Impact on CPU and I/O As stated earli
er
, paging is not in and of itself a bad thing. When starting a process the system faults in the pages of an executable, as they are needed. This is pref
er
able to loading the entire image at startup. The same can be said for memory mapped files and file system cache. All of these features lev
er
age the ability of the system to fault in pages as needed The greatest impact of paging on a process is when the process must wait for an in-page fault or when page file activity represents a significant portion of the disk activity on the disk the application is actively using. Aft
er
evaluating page fault activity, you should be able to answ
er
the following questions: What is the relationship between PageFaults/sec and Page Input/sec + Page Output/Sec? What is the relationship if any between hard page faults and available memory? Does paging activity represent a significant portion of processor or I/O resource usage? Don’t Prematurely Jump to Any Conclusions Analyzing memory pressure takes time and patience. An individual count
er
in and of it self means little. It is only when you start to explore relationships between cause and effect that you can begin to und
er
stand the impact of a particular count
er
. The key thoughts to rememb
er
are: With the exception of a swap (when the entire process’s working set has been swapped out/in), hard page faults to resolve reads, are the most expensive in t
er
ms its effect on a processes p
er
ceived p
er
formance. In gen
er
al, page writes associated with page faults do not directly affect a process’s p
er
ceived p
er
formance, unless that process is waiting on a free page to be made available. Page file activity can become a problem if that activity competes for a significant p
er
centage of the disk throughput in a heavy I/O orientated environment. That assumes of course that the page file resides on the same disk the application is using. Lab 3.1 System Memory Lab 3.1 Analyzing System Memory Using System Monitor Ex
er
cise 1 – Troubleshooting the Cardinal1.log File Students will evaluate an existing System Monitor log and det
er
mine if th
er
e is a problem and what the problem is. Students should be able to isolate the issue as a memory problem, locate the offending process, and det
er
mine wheth
er
or not this is a pool issue. Ex
er
cise 2 – Leakyapp Behavior Students will start leaky app and monitor memory, page file and cache count
er
s to bett
er
und
er
stand the dynamics of these count
er
s. Ex
er
cise 3 – Process Swap Due To Minimizing of the Cmd Window Students will start
SQL
from command line while viewing
SQL
process p
er
formance count
er
s. Students will then minimize the window and note the effect on the working set. Ov
er
view What You Will Learn Aft
er
completing this lab, you will be able to: Use some of the basic functions within System Monitor. Troubleshoot one or more common p
er
formance scenarios. Before You Begin Pr
er
equisites To complete this lab, you need the following: Windows 2000
SQL
S
er
v
er
2000 Lab Files Provided LeakyApp.exe (Resource Kit) Estimated time to complete this lab: 45 minutes Ex
er
cise 1 Troubleshooting the Cardinal1.log File In this ex
er
cise, you will analyze a log file from an actual system that was having p
er
formance problems. Like an actual support engine
er
, you will not have much information from which to draw conclusions. The custom
er
has sent you this log file and it is up to you to find the cause of the problem. Howev
er
, unlike the real world, you have an instructor available to give you hints should you become stuck. Goal Review the Cardinal1.log file (this file is from Windows NT 4.0 P
er
formance Monitor, which Windows 2000 can read). Chart the log file and begin to investigate the count
er
s to det
er
mine what is causing the p
er
formance problems. Your goal should be to isolate the problem to a major area such as pool, virtual address space etc, and begin to isolate the problem to a specific process or thread. This lab requires access to the log file Cardinal1.log located in C:\LABS\M3\LAB1\EX1 To analyze the log file 1. Using the P
er
formance MMC, select the System Monitor snap-in, and click the View Log File Data button (icon looks like a disk). 2. Und
er
Files of type, choose P
ER
FMON Log Files (*.log) 3. Navigate to the fold
er
containing Cardinal1.log file and open it. 4. Begin examining count
er
s to find what might be causing the p
er
formance problems. When examining some of these count
er
s, you may notice that some of them go off the top of the chart. It may be necessary to adjust the scale on these. This can be done by right-clicking the rightmost pane and selecting Prop
er
ties. Select the Data tab. Select the count
er
that you wish to modify. Und
er
the Scale option, change the scale value, which makes the count
er
data visible on the chart. You may need to exp
er
iment with diff
er
ent scale values before finding the ideal value. Also, it may sometimes be beneficial to adjust the v
er
tical scale for the entire chart. Selecting the Graph tab on the Prop
er
ties page can do this. In the V
er
tical scale area, adjust the Maximum and Minimum values to best fit the data on the chart. Lab 3.1, Ex
er
cise 1: Results Ex
er
cise 2 LeakyApp Behavior In this lab, you will have an opportunity to work with a partn
er
to monitor a live system, which is suff
er
ing from a simulated memory leak. Goal During this lab, your goal is to obs
er
ve the system behavior when memory starts to become a limited resource. Specifically you will want to monitor committed memory, available memory, the system working set including the file system cache and each processes working set. At the end of the lab, you should be able to provide an answ
er
to the listed questions. To monitor a live system with a memory leak 1. Choose one of the two systems as a victim on which to run the leakyapp.exe program. It is recommended that you boot using the \MAXMEM=128 option so that this lab goes a little fast
er
. You and your partn
er
should decide which s
er
v
er
will play the role of the problematic s
er
v
er
and which s
er
v
er
is to be used for monitoring purposes. 2. On the problematic s
er
v
er
, start the leakyapp program. 3. On the monitoring system, create a count
er
that logs all necessary count
er
s need to troubleshoot a memory problem. This should include physicaldisk count
er
s if you think paging is a problem. Because it is likely that you will only need to capture less than five minutes of activity, the suggested int
er
val for capturing is five seconds. 4. Aft
er
the count
er
s have been started, start the leaky application program 5. Click Start Leaking. The button will now change to Stop Leaking, which indicates that the system is now leaking memory. 6. Aft
er
leakyapp shows the page file is 50 p
er
cent full, click Stop leaking. Note that the process has not given back its memory, yet. Aft
er
approximately one minute, exit. Lab 3.1, Ex
er
cise 2: Questions Aft
er
analyzing the count
er
logs you should be able to answ
er
the following: 1. Und
er
which system memory count
er
does the leak show up clearly? Memory:Committed Bytes 2. What process count
er
looked v
er
y similar to the ov
er
all system count
er
that showed the leak? Private Bytes 3. Is the leak in Paged Pool, Non-paged pool, or elsewh
er
e? Elsewh
er
e 4. At what
point
did Windows 2000 start to aggressively trim the working sets of all us
er
processes? <5 MB Free 5. Was the System Working Set trimmed before or aft
er
the working sets of oth
er
processes? Aft
er
6. What count
er
showed this? Memory:Cache Bytes 7. At what
point
was the File System Cache trimmed? Aft
er
the first pass through all oth
er
working sets 8. What was the effect on all the processes working set when the application quit leaking? None 9. What was the effect on all the working sets when the application exited? Nothing, initially; but all grew fairly quickly based on use 10. When the s
er
v
er
was running low on memory, which was Windows spending more time doing, paging to disk or in-paging? Paging to disk, initially; howev
er
, as oth
er
applications began to run, in-paging increased Ex
er
cise 3 Minimizing a Command Window In this ex
er
cise, you will have an opportunity to obs
er
ve the behavior of Windows 2000 when a command window is minimized. Goal During this lab, your goal is to obs
er
ve the behavior of Windows 2000 when a command window becomes minimized. Specifically, you will want to monitor private bytes, virtual bytes, and working set of
SQL
S
er
v
er
when the command window is minimized. At the end of the lab, you should be able to provide an answ
er
to the listed questions. To monitor a command window’s working set as the window is minimized 1. Using System Monitor, create a count
er
list that logs all necessary count
er
s needed to troubleshoot a memory problem. Because it is likely that you will only need to capture less than five minutes of activity, the suggested capturing int
er
val is five seconds. 2. Aft
er
the count
er
s have been started, start a Command Prompt window on the target system. 3. In the command window, start
SQL
S
er
v
er
from the command line. Example:
SQL
S
er
vr.exe –c –sINSTANCE1 4. Aft
er
SQL
S
er
v
er
has successfully started, Minimize the Command Prompt window. 5. Wait approximately two minutes, and then Restore the window. 6. Wait approximately two minutes, and then stop the count
er
log. Lab 3.1, Ex
er
cise 3: Questions Aft
er
analyzing the count
er
logs you should be able to answ
er
the following questions: 1. What was the effect on
SQL
S
er
v
er
s private bytes, virtual bytes, and working set when the window was minimized? Private Bytes and Virtual Bytes remained the same, while Working Set went to 0 2. What was the effect on
SQL
S
er
v
er
s private bytes, virtual bytes, and working set when the window was restored? None; the Working Set did not grow until
SQL
accessed the pages and faulted them back in on an as-needed basis
SQL
S
er
v
er
Memory Ov
er
view
SQL
S
er
v
er
Memory Ov
er
view Now that you have a bett
er
und
er
standing of how Windows 2000 manages memory resources, you can take a clos
er
look at how
SQL
S
er
v
er
2000 manages its memory. During the course of the lecture and labs you will have the opportunity to monitor
SQL
S
er
v
er
s use of memory und
er
varying conditions using both System Monitor count
er
s and
SQL
S
er
v
er
tools.
SQL
S
er
v
er
Memory Management Goals Because
SQL
S
er
v
er
has in-depth knowledge about the relationships between data and the pages they reside on, it is in a bett
er
position to judge when and what pages should be brought into memory, how many pages should be brought in at a time, and how long they should be resident.
SQL
S
er
v
er
s primary goals for management of its memory are the following: Be able to dynamically adjust for varying amounts of available memory. Be able to respond to outside memory pressure from oth
er
applications. Be able to adjust memory dynamically for int
er
nal components. Items Cov
er
ed
SQL
S
er
v
er
Memory Definitions
SQL
S
er
v
er
Memory Layout
SQL
S
er
v
er
Memory Count
er
s Memory Configurations Options Buff
er
Pool P
er
formance and Count
er
s Set Aside Memory and Count
er
s Gen
er
al Troubleshooting Process Memory Myths and Tips
SQL
S
er
v
er
Memory Definitions
SQL
S
er
v
er
Memory Definitions Pool A group of resources, objects, or logical components that can s
er
vice a resource allocation request Cache The management of a pool or resource, the primary goal of which is to increase p
er
formance. Bpool The Bpool (Buff
er
Pool) is a single static class instance. The Bpool is made up of 8-KB buff
er
s and can be used to handle data pages or ext
er
nal memory requests. Th
er
e are three basic types or categories of committed memory in the Bpool. Hashed Data Pages Committed Buff
er
s on the Free List Buff
er
s known by their own
er
s (Ref
er
to definition of Stolen) Consum
er
A consum
er
is a subsystem that uses the Bpool. A consum
er
can also be a provid
er
to oth
er
consum
er
s. Th
er
e are five consum
er
s and two advanced consum
er
s who are responsible for the diff
er
ent categories of memory. The following list represents the consum
er
s and a partial list of their categories Connection – Responsible for PSS and ODS memory allocations Gen
er
al – Resource structures, parse head
er
s, lock manag
er
objects Utilities – Recov
er
y, Log Manag
er
Optimiz
er
– Qu
er
y Optimization Qu
er
y Plan – Qu
er
y Plan Storage Advanced Consum
er
Along with the five consum
er
s, th
er
e are two advanced consum
er
s. They are Ccache – Procedure cache. Accepts plans from the Optimiz
er
and Qu
er
y Plan consum
er
s. Is responsible for managing that memory and det
er
mines when to release the memory back to the Bpool. Log Cache – Managed by the LogMgr, which uses the Utility consum
er
to coordinate memory requests with the Bpool. Res
er
vation Requesting the future use of a resource. A res
er
vation is a reasonable guarantee that the resource will be available in the future. Committed Producing the physical resource Allocation The act of providing the resource to a consum
er
Stolen The act of getting a buff
er
from the Bpool is ref
er
red to as stealing a buff
er
. If the buff
er
is stolen and hashed for a data page, it is ref
er
red to as, and counted as, a Hashed buff
er
, not a stolen buff
er
. Stolen buff
er
s on the oth
er
hand are buff
er
s used for things such as procedure cache and SRV_PROC structures. Target Target memory is the amount of memory
SQL
S
er
v
er
would like to maintain as committed memory. Target memory is based on the min and max s
er
v
er
configuration values and current available memory as reported by the op
er
ating system. Actual target calculation is op
er
ating system specific. Memory to Leave (Set Aside) The virtual address space set aside to ensure th
er
e is sufficient address space for thread stacks, XPROCS, COM objects etc. Hashed Page A page in pool that represents a database page.
SQL
S
er
v
er
Memory Layout Virtual Address Space When
SQL
S
er
v
er
is started the minimum of physical ram or virtual address space supported by the OS is evaluated. Th
er
e are many possible combinations of OS v
er
sions and memory configurations. For example: you could be running Microsoft Windows 2000 Advanced S
er
v
er
with 2 GB or possibly 4 GB of memory. To avoid page file use, the appropriate memory level is evaluated for each configuration. Important Utilities can inject a DLL into the process address space by using HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentV
er
sion\Windows\AppInit_DLLs When the US
ER
32.dll library is mapped into the process space, so, too, are the DLLs listed in the Registry key. To det
er
mine what DLL’s are running in
SQL
S
er
v
er
address space you can use tlist.exe. You can also use a tool such as Depends from Microsoft or HandelEx from http://ww.sysint
er
nals.com. Memory to Leave As stated earli
er
th
er
e are many possible configurations of physical memory and address space. It is possible for physical memory to be great
er
than virtual address space. To ensure that some virtual address space is always available for things such as thread stacks and ext
er
nal needs such as XPROCS,
SQL
S
er
v
er
res
er
ves a small portion of virtual address space prior to det
er
mining the size of the buff
er
pool. This address space is ref
er
red to as Memory To Leave. Its size is based on the numb
er
of anticipated tread stacks and a default value for ext
er
nal needs ref
er
red to as cmbAddressSave. Aft
er
res
er
ving the buff
er
pool space, the Memory To Leave res
er
vation is released. Buff
er
Pool Space During Startup,
SQL
S
er
v
er
must det
er
mine the maximum size of the buff
er
pool so that the BUF, BUFHASH and COMMIT BITMAP structures that are used to manage the Bpool can be created. It is important to und
er
stand that
SQL
S
er
v
er
does not take ‘max memory’ or existing memory pressure into consid
er
ation. The res
er
ved address space of the buff
er
pool remains static for the life of
SQL
S
er
v
er
process. Howev
er
, the committed space varies as necessary to provide dynamic scaling. Rememb
er
only the committed memory effects the ov
er
all memory usage on the machine. This ensures that the max memory configuration setting can be dynamically changed with minimal changes needed to the Bpool. The res
er
ved space does not need to be adjusted and is maximized for the current machine configuration. Only the committed buff
er
s need to be limited to maintain a specified max s
er
v
er
memory (MB) setting.
SQL
S
er
v
er
Startup Pseudo Code The following pseudo code represents the process
SQL
S
er
v
er
goes through on startup. Warning This example does not represent a completely accurate portrayal of the steps
SQL
S
er
v
er
takes when initializing the buff
er
pool. Sev
er
al details have been left out or glossed ov
er
. The intent of this example is to help you und
er
stand the gen
er
al process, not the specific details. Det
er
mine the size of cmbAddressSave (-g) Det
er
mine Total Physical Memory Det
er
mine Available Physical Memory Det
er
mine Total Virtual Memory Calculate MemToLeave maxworkt
er
threads * (stacksize=512 KB) + (cmbAddressSave = 256 MB) Res
er
ve MemToLeave and set PAGE_NOACCESS Check for AWE, test to see if it makes sense to use it and log the results • Min(Available Memory, Max S
er
v
er
Memory) > Virtual Memory • Supports Read Scatt
er
•
SQL
S
er
v
er
not started with -f • AWE Enabled via sp_configure • Ent
er
prise Edition • Lock Pages In Memory us
er
right enabled Calculate Virtual Address Limit VA Limit = Min(Physical Memory, Virtual Memory – MemtoLeave) Calculate the numb
er
of physical and virtual buff
er
s that can be supported AWE Present Physical Buff
er
s = (RAM / (PAGESIZE + Physical Ov
er
head)) Virtual Buff
er
s = (VA Limit / (PAGESIZE + Virtual Ov
er
head)) AWE Not Present Physical Buff
er
s = Virtual Buff
er
s = VA Limit / (PAGESIZE + Physical Ov
er
head + Virtual Ov
er
head) Make sure we have the minimum numb
er
of buff
er
s Physical Buff
er
s = Max(Physical Buff
er
s, MIN_BUFF
ER
S) Allocate and commit the buff
er
management structures Res
er
ve the address space required to support the Bpool buff
er
s Release the MemToLeave
SQL
S
er
v
er
Startup Pseudo Code Example The following is an example based on the pseudo code represented on the previous page. This example is based on a machine with 384 MB of physical memory, not using AWE or /3GB. Note CmbAddressSave was changed between
SQL
S
er
v
er
7.0 and
SQL
S
er
v
er
2000. For
SQL
S
er
v
er
7.0, cmbAddressSave was 128. Warning This example does not represent a completely accurate portrayal of the steps
SQL
S
er
v
er
takes when initializing the buff
er
pool. Sev
er
al details have been left out or glossed ov
er
. The intent of this example is to help you und
er
stand the gen
er
al process, not the specific details. Det
er
mine the size of cmbAddressSave (No –g so 256MB) Det
er
mine Total Physical Memory (384) Det
er
mine Available Physical Memory (384) Det
er
mine Total Virtual Memory (2GB) Calculate MemToLeave maxworkt
er
threads * (stacksize=512 KB) + (cmbAddressSave = 256 MB) (255 * .5MB + 256MB = 384MB) Res
er
ve MemToLeave and set PAGE_NOACCESS Check for AWE, test to see if it makes sense to use it and log the results (AWE Not Enabled) Calculate Virtual Address Limit VA Limit = Min(Physical Memory, Virtual Memory – MemtoLeave) 384MB = Min(384MB, 2GB – 384MB) Calculate the numb
er
of physical and virtual buff
er
s that can be supported AWE Not Present 48664 (approx) = 384 MB / (8 KB + Ov
er
head) Make sure we have the minimum numb
er
of buff
er
s Physical Buff
er
s = Max(Physical Buff
er
s, MIN_BUFF
ER
S) 48664 = Max(48664,1024) Allocate and commit the buff
er
management structures Res
er
ve the address space required to support the Bpool buff
er
s Release the MemToLeave Tip Trace Flag 1604 can be used to view memory allocations on startup. The cmbAddressSave can be adjusted using the –g XXX startup paramet
er
.
SQL
S
er
v
er
Memory Count
er
s
SQL
S
er
v
er
Memory Count
er
s The two primary tools for monitoring and analyzing
SQL
S
er
v
er
memory usage are System Monitor and DBCC MEMORYSTATUS. For detailed information on DBCC MEMORYSTATUS ref
er
to Q271624 Int
er
preting the Output of the DBCC MEMORYSTAUS Command. Important Represents
SQL
S
er
v
er
2000 Count
er
s. The count
er
s presented are not the same as the count
er
s for
SQL
S
er
v
er
7.0. The
SQL
S
er
v
er
7.0 count
er
s are listed in the appendix. Det
er
mining Memory Usage for OS and BPOOL Memory Manag
er
: Total S
er
v
er
memory (KB) - Represents all of
SQL
usage Buff
er
Manag
er
: Total Pages - Represents total bpool usage To det
er
mine how much of Total S
er
v
er
Memory (KB) represents MemToLeave space; subtract Buff
er
Manag
er
: Total Pages. The result can be v
er
ified against DBCC MEMORYSTATUS, specifically Dynamic Memory Manag
er
: OS In Use. It should howev
er
be noted that this value only represents requests that went thru the bpool. Memory res
er
ved outside of the bpool by components such as COM objects will not show up h
er
e, although they will count against
SQL
S
er
v
er
private byte count. Buff
er
Counts: Target (Buff
er
Manag
er
: Target Pages) The size the buff
er
pool would like to be. If this value is larg
er
than committed, the buff
er
pool is growing. Buff
er
Counts: Committed (Buff
er
Manag
er
: Total Pages) The total numb
er
of buff
er
s committed in the OS. This is the current size of the buff
er
pool. Buff
er
Counts: Min Free This is the numb
er
of pages that the buff
er
pool tries to keep on the free list. If the free list falls below this value, the buff
er
pool will attempt to populate it by discarding old pages from the data or procedure cache. Buff
er
Distribution: Free (Buff
er
Manag
er
/ Buff
er
Partition: Free Pages) This value represents the buff
er
s currently not in use. These are available for data or may be requested by oth
er
components and mar
CE中文版-启点CE过NP中文.exe
启点CE过NP中文Decemb
er
24 2018:Cheat Engine 6.8.2 Released: H
er
e's a new v
er
sion for the hollidays. Mainly minor improvements and some small bugfixes, but also a new 'ultimap like' feature called Code Filt
er
for which you don't need any special hardware for. (Just an extensive list of addresses) Download: Cheat Engine 6.8.2 Fixes: Disassembl
er
: Sev
er
al disassembl
er
instructions had a comma too many or too few ,fixed those Disassembl
er
: Fixed the description for ret # Disassembl
er
/Debug: Fixed the address that is being edited when a break
point
hits while editing an instruction Assembl
er
: Fixed assembling reg*2/4/8+unquotedsymbol Plugin: Fixed the SDK for C plugins that use the disassembl
er
callback Hotkeys: Fixed the attach to foreground hotkey Memory Scan: Fixed the p
er
centage scan Memory Scan: Fixed a rare situation that could cause an
er
ror Memory Scan: Simple values now works with groupscan Memory Scan Lua: Scanfiles now also get deleted if the memory scan object is freed before the scan is fully done Fill Memory: Now allows 64-bit addresses Structure Dissect: Fixed the popupmenu "change type" so it now affects all selected entries instead of just the first
Point
er
Or
Point
ee window: Fix the debug
point
er
or
point
ee window button text when using access instead of writes GUI: Fixed and restored the DPI Aware option in setting GUI: Some DPI fixes/adjustments h
er
e and th
er
e Graphical Memory view: Fixed DPI issues Symbolhandl
er
: When the symbolhandl
er
now waits till it's done, it won't wait for the structures to be parsed anymore Additions and Changes: Lua Engine: Added autocomplete DLL injection: On DLL injection failure CE tries to fall back on forced injection methods Assembl
er
: Added multibyte NOP Plugins: Plugins can now have side dll's that are statically linked in their own fold
er
(Windows 7 with updates and lat
er
) Debugging: Improved the FPU window editing when single stepping, allowing you to change the FPU regist
er
s Debugging: Threadview now updates when single stepping and cnanges made th
er
e will affect the currently debugged thread (before it didn't) Debugging: Added Code Filt
er
. This lets you filt
er
out code based on if it has been executed or not (Uses software break
point
s) Debugging: Added an option to chose if you wish to break on unexpected break
point
s, and if CE should break on unexpected break
point
s, or only on specified regions (like AA scripts) Disassembl
er
: The comments now show multiple paramet
er
s
Point
er
scan: Add option to allow negative offset scanning
Point
er
scan: Add extra types to the display Advanced Options/CodeList: Now uses symbolnames Tutorial Game: Added a levelskip option when you've solved a step Tutorial Game: Added a secondary test Compare memory: Added a limit to the numb
er
of address values shown p
er
row (can be changed) Address List: When the option to deactivate children is set, the children will get deactivated first Memory Scan: Add a lua script in autorun that lets you specify which module to scan Lua: ExecuteCodeEx(Let's you execute code in the target and pass paramet
er
s) Added 2 new paramet
er
s to getNameFromAddress (ModuleNames and Symbols) Added addModule and deleteModule to the symbollist class Added the ModuleLoad
er
class which can force load dll's Fixed endUpdate for the listview Thanks go out to S
ER
[G]ANT for updating the russion translation files already June 23 2018:Cheat Engine 6.8.1 Released: Apparently 6.8 contained a couple of annoying bugs, so h
er
e's an update that should hopefully resolve most issues. Also a few new features that can come handy Download: Cheat Engine 6.8.1 Fixes: Fixed sev
er
al issues with the structure compare Fixed the commonality scann
er
from picking up unrelated regist
er
s for comparison Fixed speedhack hotkeys Fixed ultimap 1 Fixed a bunch of random access violations Fixed Lua dissectCode.getStringRef
er
ences now also returns the string Fixed Lua break
point
s that specify a specific function Fixed Lua toAddress when the 2nd paramet
er
is an address Fixed assembling xmm,m32 Fixed issue when disassembling AVX instructions Fixed rightclicking r8-r9 in the regist
er
s window Fixed the plugin system for DBVM Fixed DBVM memory allocations when small
er
than 4KB Additions and changes: Added translation strings for the all type settings You can now drop files into the auto assembl
er
auto assembl
er
commands allocnx (allocate no execute) and allocxo (allocate execute only) The memoryview windows's hexadecimalview now shows the allocationbase as well, and can be doubleclicked to go th
er
e Added support for mono dll's that do not export g_free Changed "make page writable" to multiple options Improved DBVM speed slightly Lua: added RemoteThread class object June 8 2018:Cheat Engine 6.8 Released: Cheat Engine 6.8 has been released. Lots of new features like structure compare, AVX disassembling support, lua functions, etc... Download: If you encount
er
bugs or have suggestions, please do not hesitate to report them in the forum, bugtrack
er
or by e-mail. And if you have questions, don't hesitate to ask them in the forum Fixes: Fixed some more high dpi issues Fixed issues with the dropdown list in memory records Fixed
point
er
offset symbols not calculating prop
er
ly Fixed regist
er
ed binutils Fixed graphical issues with the tablist Fixed issue wh
er
e memory blocks would get cut of before the page end Fixed some memory leaks Fixed some graphical issues in the addresslist Fixed rightclick on r8 and r9 in memoryview Fixed disassembling some instructions Fixed DBVM so it works on windows 1709 and lat
er
(tested on 1803) Fixed sev
er
al DBVM offload crashes Fixed freeze with allow increase/decrease for 8 byte long values Fixed sev
er
al issues wh
er
e minimizing a window and then close it would hang CE Fixed file scanning Fixed crashes when editing memory in some some emulators Additions and changes: Text editor improvements Added hundreds of new cpu instructions Mono now has some new features like instancing of objects Mono instances window is now a treeview wh
er
e you can see the fields and values "find what addresses this code accesses" can also be used on RET instructions now (useful to find call
er
s) The graphical memory view now has a lot more options to set it just the way you need Codepage support in hexview structure data from PDB files can now be used, and are stored in a database for lookup lat
er
dissect structures form can now show a list of known structures (pdb, mono, ...) Added a "rev
er
t to saved scan" option (lets you undo changes) Added a "forgot scan" option (in case you forgot what you're doing)
Point
er
scan limit nodes is default on in a new ce install (rememb
er
s your choice when you disable it) Autoattach now happens using a thread instead of a gui blocking tim
er
Some colorscheme enhancements Added a DBVM based "Find what writes/accesses" feature. (For pro us
er
s, enable k
er
nelmode options for it to show) Changed the dissect data setup from sep
er
ate yes/no/value dialogs to a single window Added a bypass option for ultimap2 on windows 1709. When using ranges, do not use int
er
rupts, or use DBVM Added find what writes/access to the foundlist Autoassembl
er
scriptblocks are now grouped when written to memory Added {$try}/{$except} to auto assembl
er
scripts Added an extra tutorial/practice target Added cut/copy/paste context menu items to
point
er
offset fields in add/change address, and added a context menu to the
point
er
destination Added an automated structure compare for two groups of addresses to find ways to distinguish between them lua: added automatic garbage collection and settings to configure it added new functions: gc_setPassive gc_setActive reinitializeSelfSymbolhandl
er
regist
er
StructureAndElementListCallback showSelectionList changed the getWindowlist output MainForm.OnProcessOpened (bett
er
use this instead of onOpenProcess) enumStructureForms cpuid getHotkeyHandl
er
Thread bunch of dbvm_ functions (needs dbvm capable cpu, and intel only atm) and more, including class methods and fields (read celua.txt) Minor patches: 06/08/2018: 6.8.0.4 - Fixed speedhack hotkey speed asignments and some commonalityscann
er
issues 06/09/2018: 6.8.0.5 - Fixed only when down speedhack option 06/10/2018: 6.8.0.6 - Fixed ultimap1 - Fixed ultimap2 on some systems - Fixed enableDRM() from crashing - Fixed one disassembl
er
instruction Russian translation has been updated Novemb
er
13 2017:Can't run Cheat Engine Th
er
e is apparently some malware going around that blocks execution of Cheat Engine (Saying file missing, check filename, etc...) If you have been a victim of this then try this windows repair tool to fix your windows install: Download Repair Tool Novemb
er
9 2017:Spanish(Latin) translation added Manuel Ibacache M. from Chile has provided us with spanish(Latin) translation files for Cheat Engine. They can be downloaded from the download section wh
er
e you can find the oth
er
translation files, or right h
er
e June 7 2017:Cheat Engine 6.7 Released: Cheat Engine 6.7 has been released. New lua functions, GUI improvements, codepage scanning, sev
er
al bugfixes and more(See below). Download: Cheat Engine 6.7 If you encount
er
bugs or have suggestions, please do not hesitate to report them in the forum, bugtrack
er
, irc or by e-mail. And if you have questions, don't hesitate to ask them in the forum , irc Fixes: Fixed some DPI issues at some spots Fixed the "Not" scan for ALL "simple values" now also applies to the All type Fixed not adding the 0-t
er
minator to strings when the option was set to add it Fixed ultimap hotkeys Fixed ultimap2 filt
er
ing Changing
point
er
s in the change address dialog won't set/ov
er
ride global memrec and address anymore (local now) Fixed show as signed not working for custom types Fixed sev
er
al issues with the structure spid
er
Fixed 64-bit regist
er
s in the trac
er
getting truncated on doubleclick, and fix r8 to r15 Fixed copy/paste in the scanvalue Fixed k
er
nelmode Qu
er
yMemoryRegions for windows build 1607 Fixed some disassembl
er
er
rors Fixed lua command fullAccess Fixed text to speech if launched from a diff
er
ent thread Fixed clicking on checkboxes when the dpi is diff
er
ent Fixed the found code dialog count size Fixed mono freezing Cheat Engine when it crashes/freezes Additions and changes: Changed the processlist and added an Applications view similar to the taskmanag
er
Small change to the tutorial first step wording Structure Dissect: Added RLE compression (by mgr.inz.play
er
) and oth
er
things to improve filesize Structure Dissect: If setting a name, it will also be shown in the head
er
The symbolhandl
er
can now deal with complex
point
er
notations Added support for single-ToPA systems for ultimap2 Added some more spots wh
er
e the history will be remeb
er
ed in memoryview Memoryrecords with auto assembl
er
scripts can now execute their code asynchronous (rightclick and set "Execute asynchronous") K
er
nelmode memory reading/writing is saf
er
now Added an option to filt
er
out readable paths in the
point
er
scan rescan Added "codePage" support Added font/display options to sev
er
al places in CE Added a search/replace to the script editors You can now delete addresses and reset the count from "Find what addresses this code accesses" Added a statusbar to the hexview in memoryview
Point
er
scan for value scans now add the results to the ov
er
flow queue Opening a file and changing bytes do not change them to the file anymore (you need to explicitly save now) Added an option to the processlist to filt
er
out system processes Added a system to let us
er
s sign their tables so you know you can trust their tables. Memory record dropdown lists can now ref
er
ence those of oth
er
s. USe as entry text: (memoryrecorddescription) Added an option to notify us
er
s of new v
er
sions of Cheat Engine lua: Custom Types can now be ref
er
enced from Lua Auto assembl
er
lua sections now have access to "memrec" which is the memory record they get executed from. Can be nil stringToMD5String now support strings with a 0 byte in them autoAssemble() now also returns a disableInfo object as 2nd paramet
er
. You can use this to disable a script added Action and Value prop
er
ties to MemoryRecordHotkey objects added screenToClient and clientToScreen for Control objects added readSmallInteg
er
and writeSmallInteg
er
added enableDRM() added openFileAsProcess/saveOpenedFile added saveCurrentStateAsDesign for CEForm objects added disableWithoutExecute and disableAllWithoutExecute added OnCustomDraw* events to the listview added being/endUpdate for the Strings class added
SQL
support added color ov
er
rides to the disassembl
er
text added OnPaint to the CustomControl class added autoAssembleCheck to syntax check an AA script fixed the addresslist returning nil for PopupMenu (while popupMenu did work) added an timeout option for pipes added some graphical options added some low level system functions Russian translation has been updated Chinese translation has been updated May 15 2017:Korean language files Thanks to Petrus Kim th
er
e are now Korean language files for Cheat Engine. You can get them h
er
e Just extract it to the language fold
er
in the Cheat Engine installation fold
er
and you'll be able to use it April 13 2017:Cheat Engine for Macintosh download For the Mac us
er
s und
er
us th
er
e is now a mac v
er
sion available for download. It's based on Cheat engine 6.2 but I will be upgrading it to 6.6 and lat
er
based on the feedback I get. Tip:if you have trouble opening processes: Reboot your Mac and hold CMD+R during boot to ent
er
the recov
er
y console. Th
er
e open the t
er
minal (using the top menu) and ent
er
"csrutil disable" . Then reboot and you'll be able to open most processes (Youtube video by NewAgeSoldi
er
in case it's not clear) Octob
er
6 2016:Cheat Engine 6.6 Released: Cheat Engine 6.6 has been released. It has sev
er
al fixes, new scan functionality, gui changes/improvements, Ultimap 2, bett
er
hotkeys, more programming options, and more(See below). Download: Cheat Engine 6.6 If you encount
er
bugs or have suggestions, please do not hesitate to report them in the forum, bugtrack
er
, irc or by e-mail. And if you have questions, don't hesitate to ask them in the forum or irc Fixes: Fixed saving of hotkey sounds Fixed the CF flag in the disassembl
er
stepping mode Fixed K
er
nelmode VirtualQu
er
yEx for Windows 10 build 14393 Fixed DBVM for Windows 10 build 14393 Fixed the shortest assembl
er
instruction picking for some instructions Fixed a few bugs in the break and trace routine when you'd stop it while the thread still had a single step set Fixed sev
er
al ansi to UTF8 incompatbilities that poped up between 6.5 and 6.5.1 Fixed the stackview not prop
er
ly setting the color, and giving an
er
ror when trying to change a color Fixed the exe gen
er
ator not adding both .sys files or the .sig files when using k
er
nel functions Fixed some places of the disassembl
er
wh
er
e it helps guessing if something is a float or not When using the code find
er
, it won't show the previous instruction anymore if it's on a REP MOVS* instruction Fixed an issue when editing memoryrecords with strings, wh
er
e wordwrap would add newline charact
er
s Fixed D3D alpha channel for textures and fontmaps Fixed the helpfile not being searchable The install
er
will now mark the CE destination fold
er
as accessible by APPS. (fixes speedhack for some APPS) Fixed the form designed crashing is resized 'wrong' Additions and changes: Ultimap 2 for Intel CPU's of gen
er
ation 6 and lat
er
(no DBVM needed for those) Language select if you have multiple language files for CE Memoryrecord
point
er
offsets can use calculations, symbols and lua code now While stepping in the debugg
er
you can now easily change the EIP/RIP regist
er
by pressing ctrl+f4 changed the way CE is brought to front when a hotkey is pressed Made the GUI more adaptive to diff
er
ent fontsizes and DPI Sev
er
al font and minor GUI changes Added DPIAware and a font ov
er
ride to the settings window. (DPI aware is on by default, but can be turned of if exp
er
iencing issues) Added option to enable pause by default Disassembling mega jumps/calls now show the code in one line The standalone auto assembl
er
window will now give an option to go to the first allocated memory address Changed the
point
wh
er
e the settings are loaded in CE's startup sequence The formdesign
er
now allows copy and paste of multiple objects, and uses text Added scrollbox and radiogroup to the formdesign
er
Added Middle, MB4 and MB5 as allowable hotkeys Added controll
er
keys as hotkeys Single stepping now shows an indication if an condition jump will be taken Added a watchlist to the debugg
er
Added the 'align' assembl
er
pseudo command (allocates memory so the next line is aligned on a block of the required size) Added the 'Not' option for scans, which causes all addresses that match the given entry as
invalid
Changed the Unicode text to UTF-16. Text scans are now UTF8/UTF16 (no codepage) Hexview can now show and edit values in 3 diff
er
ent textencodings. (Ascii, UTF-8 and UTF-16) Rescan
point
er
scans on
point
er
scans that wh
er
e done on a range can now change the offset lua: speak(): Text to speech hookWndProc: a function that lets you hook the windows message handl
er
of a window regist
er
EXETrain
er
Feature: Lets you add extra files to the exe train
er
file pack
er
getFileV
er
sion(): A function to get v
er
sion information from a file mouse_event() : Lets you send mouse events to windows. (move, click, etc...) loadFontFromStream() : Lets you load a font from a memory stream. (Useful for train
er
s that use a custom font) added sev
er
al thread synchronization objects control class: added bringToFront and sendToBack lua changes: dbk_writesIgnoreWriteProtection() now also disables virtualprotectex calls from CE loadTable() can now also load from a Stream object. the addresslist has some Color prop
er
ties published for bett
er
customization the LUA s
er
v
er
has had some new commands added so hooked code can do more efficient calls. (LUAClient dll has been updated to use them in a basic way) Russian translation has been updated French tutorial only translation has been updated as well 10/10/2016:6.6.0.1: Fixed align May 19 2016:Cheat Engine 6.5.1 Released: 6.5.1 has been released. It's mainly a bugfix v
er
sion to replace 6.5 which had a few minor bugs that needed solving. Download: Cheat Engine 6.5.1 Fixes: Fixed increased value by/decreased value by for float values Fixed disassembling/assembling some instructions (64-bit) Fixed the autoassembl
er
tokenizing wrong words Fixed sev
er
al bugs related to the structure dissect window (mainly shown when autodestroy was on) Fixed a small saving issue Groupscans now deal with alignment issues bett
er
Fixed java support for 32-bit Additions and changes: Signed with a sha256 signature as well (for OS'es that support it) Changed Ultimap to use an official way to get the p
er
fmon int
er
rupt instead of IDT hooking (less BSOD on win10 and 8) Individual hotkeys can now play sounds Now compiled with fpc 3.0/lazarus 1.6 (Previously 2.7/1.1) You can now search in the string list PEInfo now has a copy to clipboard Some places can now deal bett
er
with mistakes Lazarus .LFM files can now be loaded and saved lua: Fixed sev
er
al incompatibilities between lua that popped up in 6.5 (due to the lua 5.1 to 5.3 change) Fixed the OnSelectionChange callback prop
er
ty in the memoryview object MemoryRecords now have an Collapsed prop
er
ty Added TCanResizeEvent to the splitt
er
Fixed setBreak
point
not setting a prop
er
trigg
er
if not provided Fixed executeCode* paramet
er
passing Fixed sev
er
al memory leaks wh
er
e unregist
er
ing hooks/addons didn't free the int
er
nal call object Some tableFile additions Fixed regist
er
Assemble assembl
er
commands Added k
er
nelmode alloc and (un)mapping functionality Added an easy way to add auto assembl
er
templates Added window related functions including sendMessage Added Xbox360 controll
er
support functions Added more thread functions Post release fixes: Dealt with sev
er
al gui issues like the mainform to front on modal dialogs, head
er
resizing stuck with the cursor, treeview item selection/deletion being weird, etc... Added a disconnect to the client in
point
er
scans Fixed
point
er
scan issue with 32-bit aligned
point
er
s in a 64-bit process Fixed a deadlock in threads when lua custom types wh
er
e used Post release fixes: Dealt with sev
er
al gui issues like the mainform to front on modal dialogs, head
er
resizing stuck with the cursor, treeview item selection/deletion being weird, etc... Added a disconnect to the client in
point
er
scans fixed
point
er
scan issue with 32-bit aligned
point
er
s in a 64-bit process Fixed a deadlock in threads when lua custom types wh
er
e used Fixed
point
er
scan resume 6/1/2016: (major bugfix) prop
er
ly fixed resume of
point
er
scans and alignment fix Decemb
er
31 2015:Cheat Engine 6.5 Released: I'd like to announce the release of Cheat Engine 6.5 If you encount
er
bugs or have suggestions, please do not hesitate to report them in the forum, bugtrack
er
, irc or by e-mail. And if you have questions, don't hesitate to ask them in the forum or irc Fixes: Fixed page exception break
point
s from not working Fixed the save as button in the lua script assigned to the table Fixed the dotnetdatacollector from not fetching parent fields Fixed disassembling of some instructions Fixed assembling some instructions Fixed assembling instructions that ref
er
enced address 80000000 to ffffffff in 64-bit targets Fixed dealing with unexpected break
point
s Fixed sev
er
al issues with the network scann
er
. (symbols, scanspeed, threads, etc...) Fixed "going to" 64-bit regist
er
s. Fixed
point
er
strings for 64-bit Fixed the addresspars
er
in memview's hexview not handing static 64-bit addresses Fixed r8 and r9 looking broken in the memoryview window Fixed hotkeys that set a value as hexadecimal and the value is small
er
than 0x10 Fixed multiline string editing for memory records Fixed dragging cheat tables into CE Fixed VEH debug for 'Mod
er
n' apps Fixed sev
er
al translation issues lua: fixed getStructureCount, writ
eR
egionToFile, readRegionFromFile, readInteg
er
, ListColum.GetCount fixed memoryleak in MemoryStream Sev
er
al fixes to DBVM: added support for Windows 10 support for more than 8 cpu's support for new
er
cpu's fixed issue wh
er
e calling CPUID right aft
er
setting the TF flag wouldn't trigg
er
a break
point
aft
er
it Additions and changes: Array of Byte's can now deal with nibble's. (e.g: 9* *0 90 is now a valid input- and scanstring) The auto assembl
er
can now deal with some mistakes like forgetting to declare a label Added support to use binutils as assembl
er
and disassembl
er
, and a special scripting language for it Added support for 64-bit mono, and script support for cases wh
er
e mono.dll isn't called mono.dll Added an option to get a list of all recently accessed memory regions. This is useful for the
point
er
scann
er
The
point
er
scann
er
can now use multiple snapshots (
point
er
maps) to do a scan. This basically lets you do a rescan during the first scan, saving your harddisk Made the
point
er
scan network scann
er
a bit easi
er
to use. You can now join and leave a
point
er
scan session You can now stop
point
er
scans and resume them at a lat
er
time
Point
er
scan files can get conv
er
ted to and from
sql
ite database files The
point
er
scan configuration window now has an advanced and basic mode display The all type now has a setting that lets you define what und
er
"all" falls Custom types now also have access to the address they're being used on Split up the "(de)activating this (de)activates children" into two sep
er
ate options (one for activate, one for deactivate) Added some basic Thumb disassembling The xmplay
er
has been replaced with mikmod which supports many diff
er
ent module types (in lua you still call it xmplay
er
) Rightlicking on "your system supports dbvm" will let you manually load DBVM for each cpu. This is usefull if for some reason your system crashes when it's done too quickly In "Find what addresses this instruction accesses" you can now open the structure dissect window of your choice in case th
er
e are oth
er
s. It will also fill in the base address, so no need to recalculate yourself AA command GlobalAlloc now has an optional 3th paramet
er
that lets you specify the pref
er
ed region Added an option to record and undo writes. (Off by default, can be enabled in settings. Memview ctrl+z will undo the last edit) Added aobscanregion(name,startaddress,stopaddress,aob) lua: switched from Lua 5.1 to 5.3 debug_setBreak
point
can now take an OnBreak
point
paramet
er
that lets you set a specific function just for that break
point
added dbk_getPhysicalAddress(int) added dbk_writesIgnoreWriteProtection(bool) added getWindowList() And a bunch of oth
er
lua functions. (check out main.lua) Post release fixes (max 7 days aft
er
initial release *or 30 if a HUGE bug): 1/6/2016:Fixed structure dissect from crashing when autodestroy is on 1/6/2016:Fixed window position loading on multi monitor systems 1/6/2016:Fixed the lua customtype and 1/6/2016:Sev
er
al minor gui fixe
UNet(PyTorch)图像语义分割实战:训练自己的数据集
UNet是一种基于深度学习的图像语义分割方法,尤其在医学图像分割中表现优异。 本课程将手把手地教大家使用labelme图像标注工具制作自己的数据集,生成Mask图像,并使用PyTorch版UNet训练自己的数据集,从而能开展自己的图像分割应用。 本课程有两个项目实践: (1) Kaggle盐体识别比赛 :利用PyTorch版UNet进行Kaggle盐体识别 (2) Pothole语义分割:对汽车行驶场景中的路坑进行标注和PyTorch版UNet语义分割 本课程使用PyTorch版本的UNet,在Ubuntu系统上用Jupyt
er
Notebook做项目演示。 包括:数据集标注、数据集格式转换和Mask图像生成、编写UNet程序文件、训练自己的数据集、测试训练出的网络模型、性能评估。项目代码也可在Windows上运行,课程提供Windows环境搭建方法。本课程提供项目的数据集和Python程序代码。
BobBuild
er
_app
Twitt
er
Digg Facebook Del.icio.us Reddit Stumbleupon Newsvine Technorati Mr. Wong Yahoo! Google Windows Live Send as Email Add to your CodeProject bookmarks Discuss this article 85 Print Article Database » Database » Oth
er
databasesLicence CPOL First Posted 19 Jan 2012 Views 24,219 Downloads 992 Bookmarked 74 times RaptorDB - The Key Value Store V2 By Mehdi Gholam | 8 Mar 2012 | Unedited contribution C#.NETDBABeginn
er
Int
er
mediateAdvanceddatabase Even fast
er
Key/Value store no
sql
embedded database engine utilizing the new MGIndex data structure with MurMur2 Hashing and WAH Bitmap indexes for duplicates. See Also More like this More by this author Article Browse Code Stats Revisions (8) Alt
er
natives 4.95 (56 votes) 1 2 3 4 5 4.95/5 - 56 votes μ 4.95, σa 1.05 [?] Is your email address OK? You are signed up for our newslett
er
s but your email address is eith
er
unconfirmed, or has not been reconfirmed in a long time. Please click h
er
e to have a confirmation email sent so we can confirm your email address and start sending you newslett
er
s again. Alt
er
natively, you can update your subscriptions. Add your own alt
er
native v
er
sion Introduction What is RaptorDB? Features Why anoth
er
data structure? The problem with a b+tree Requirements of a good index structure The MGIndex Page Splits Int
er
esting side effects of MGIndex The road not taken / the road taken and doubled back! P
er
formance Tests Comparing B+tree and MGIndex Really big data sets! Index paramet
er
tuning P
er
formance Tests - v2.3 Using the Code Diff
er
ences to v1 Using RaptorDBString and RaptorDBGuid Global paramet
er
s RaptorDB int
er
face Non-clean shutdowns Removing Keys Unit tests File Formats File Format : *.mgdat File Format : *.mgbmp File Format : *.mgidx File Format : *.mgbmr , *.mgrec History Download RaptorDB_v2.0.zip - 38.7 KB Download RaptorDB_v2.1.zip - 39 KB Download RaptorDB_v2.2.zip - 39 KB Download RaptorDB_v2.3.zip - 39.6 KB D
munmap_chunk():
invalid
point
er
现象:munmap_chunk():
invalid
point
er
问题分析: sprintf(
sql
,"ins
er
t ...."); 执行
sql
语句,运行报上述
错误
结果:发现是
sql
数组定义过小导致的,编译时无法提示这样的
错误
!
数据库
4,011
社区成员
39,816
社区内容
发帖
与我相关
我的任务
数据库
VC/MFC 数据库
复制链接
扫一扫
分享
社区描述
VC/MFC 数据库
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章